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Preface 


Decision  Support  Systems  (DSS*s)  are  combinations  of  computer  hardware 
and  software  designed  to  assist  decision  makers  in  making  complex  decisions. 
DSS’s  extend  the  capabilities  of  management  information  systems  (MIS’s) 
primarily  by  providing  additional  analytical  capability  for  examining  the 
impacts  of  alternative  decisions.  This  report  documents  an  initial  research 
effort  under  the  Improvonent  of  Operations  and  Management  Techniques 
(lOMT)  Research  ^gram  q;>onsored  by  the  Headquarters,  U.S.  Army  Corps 
of  Engineers  (HQUSACE)  Goieral  Investigation  Program  under  Work  Unit 
32717,  "The  Application  of  Decision  Support  Systems  to  O&M  Budget 
Managemoit,"  to  explore  the  potential  of  DSS  to  assist  decision  makers  within 
the  Opmtions,  Cbnstmction  and  Readiness  (OCR)  Division.  The  Corps  of 
Engineos  Operations  and  Management  Budget  Decision  Support  System 
(COMB^DSS)  is  a  working  DSS,  tested  during  the  fiscal  year  (FY)  1994 
budget  cycle,  that  demonstrates  the  potential  for  DSS  within  the  OCR  Divi¬ 
sion.  The  research  team  plans  to  continue  to  explore  the  potential  of  DSS. 

This  project  research  was  a  team  effort  lOMT  researchers  and  the  users  of 
the  DSS  combined  to  cortceive,  design,  implement  and  evaluate  the 
COMB_DSS.  The  pivotal  member  of  the  team  was  Mr.  Dave  Harmon, 
HQUSACE.  Mr.  Harmon  was  the  primary  user  of  the  prototype  COMBJDSS 
and  ^)ent  many  hours  helping  the  research  team  develc^  and  improve  the 
syston.  The  success  of  tto  effort  would  have  bear  impossible  without  his 
help.  Plarming  and  Managemoit  Consultants,  Limited  (PMCL),  provided 
technical  support  unda  contract  to  the  U.S  Army  Engineer  Institute  for  Wata 
Resources  (IWR).  Mr.  Qaig  A.  Strus  was  PMCL’s  project  manager. 

Mr.  Richard  M.  Males,  RMM  Technical  Services,  Inc.,  a  subcontractor  to 
PMCL,  was  instrumental  in  the  design  effort  and  was  primarily  re^nsible  for 
budding  the  working  prototype.  Mr.  Midiael  R.  Walsh,  Technical  Analysis 
and  Research  Division,  IW^  managed  the  PMCL  contract  and  worked  directly 
with  Mr.  Harmon  during  the  FY  94  budget  process  to  refine  the  COMB_DSS. 
Mr.  Stephoi  H.  Scott,  Estuarine  Engineering  Branch,  Estuaries  Division, 
Hydraulics  Laboratory,  U.S.  Army  Engineer  Waterways  Ejqperiment  Station 
(WES),  participated  in  the  review  process  for  eadi  version  of  the  COMB_pSS 
and  is  the  co-principal  investigator  with  Mr.  Walsh  for  the  lOMT  work  unit  on 
DSS  that  supported  the  develt^oit  of  the  COMB_DSS.  Ms.  Connie  L. 
Raaymakos  and  Mr.  Edward  J.  Japtl,  U.S.  Army  Construction  Engineoing 
Research  Laboratory,  provided  insight  into  the  existing  Automated  Budget 
Syston  (ABS),  and  Ms.  Raaymakeis  provided  much  of  the  technical  evaluation 


of  the  COMB_DSS  during  the  FY  94  budget  process.  Ms.  M.  Cathy  Ballard, 
Information  Technology  Laboratory,  WES,  is  working  on  the  port  of  the  ABS 
database  to  the  ORACLE  database  management  system  and  provided  helpful 
information  for  the  design  of  the  database  componoit  of  the  COMB_DSS. 

This  report  was  written  by  Messrs.  Strus,  Russ  E.  Robinson,  PMCL,  Males, 
Walsh,  Japel,  and  Ms.  Raaymakers. 

Messrs.  Jim  Crews  and  Mr.  Robert  Daniel,  HQUSACE,  were  Technical 
Monitors;  and  Mr.  Robert  F.  Athow,  Estuaries  Division,  was  the  lOMT  Pro¬ 
gram  Manager.  The  contract  was  monitored  by  Messrs.  Walsh  and  Scott 
Contracting  Officer  was  COL  Leonard  G.  Hassell,  EN.  At  the  time  of  publica¬ 
tion  of  this  report.  Director  of  WES  was  Dr.  Robert  W.  Whalin.  Commander 
was  COL  Bruce  K.  Howard,  EN. 


Summary 


This  report  describes  the  development  and  use  of  a  personal  computer-based 
decision  support  system  to  assist  with  operations  and  maintenance  (O&M) 
budget  analysis,  llie  Corps  of  Engineers  Operations  and  Maintenance  Budget 
Decision  Support  System  (COMBJDSS)  is  the  first  product  of  the  work  unit 
entitled,  "Decision  Support  Systems  for  Operations  and  Maintenance,”  under 
the  Impiovemoit  of  Operations  and  Managonent  Techniques  (lOMT)  reseaidi 
program.  The  objectives  of  the  COMB_DSS  effort  were  to  assist  the 
Opoations,  Construction  and  Readiness  (OCR)  Division,  Headquarters, 

U.S.  Army  Corps  of  Engineers  (HQUSACE),  with  analysis  and  decision 
making  about  yearly  budget  submittals  by  Corps  Divisions  and  to  demonstrate 
the  potential  of  decision  support  systems  for  assisting  the  OCR  Division  with 
crucial  decision  making,  llie  project  was  successful  on  both  counts. 

Much  of  the  success  of  the  effort  can  be  attributed  to  the  approach  used  to 
develop  the  COMB_DSS.  The  project  was  highly  focused  on  a  well-defined, 
relevant  problem.  Ihe  Automat  Budget  System  (ABS)  off^ed  a  database 
framework  on  which  the  decision  support  systmn  could  be  built  The  project 
team  included  perscmnel  from  the  U.S.  Army  Engines  Institute  for  Water 
Resources,  U.S.  Army  Construction  Engineering  Research  Laboratory,  and 
U.S.  Army  Engineer  Waterways  E]q>eriment  Station  who  were  famUiar  with 
the  existing  ABS  system  as  well  as  the  principles  for  sound  decision  suiE^rt 
system  development  The  team  worited  directly  with  the  primary  user  cf  the 
system  to  ensure  that  the  syston  Reformed  crucial  tasks  effectively.  The 
COMBJDSS  was  developed  using  an  iterative,  rapid  prototyping  approach. 
Rather  than  spend  considerable  time  and  effort  in  developing  detail^  require¬ 
ments  and  design  ^>ecifications  before  coding  and  testing,  a  version  of  the 
COMBJDSS  was  built  early  in  the  development  process,  based  on  prdiminary 
requirements  and  design  specifications.  This  allowed  the  usct  hands-on 
experience  with  the  syston  very  early  in  the  devdopment  cycle,  therdry  pro¬ 
viding  the  devdopment  team  with  rapid  feedback  on  ahat  worited  and  what 
did  not  work.  Thus,  the  design  team  was  able  to  reqwnd  quickly  with 
improved  aqrabilities. 

The  COMBJDSS  works  with  the  existing  ABS  budget  data  that  are  transmitted 
to  HQUSACE  each  year  from  Districts  and  Divisions.  ABS  data  contain 
information  about  rqrproxinutdy  20,000  work  functions  that  are  candidates  for 
funding  in  the  budget  process.  These  work  functions  have  been  prioritized  by 
Districts  and  Divisions,  are  analyzed  by  the  OCR  Division  in  tmms  of  nationd 


viU 


objectives,  and  ultimately  ranked  in  flnal  order  of  preference.  This  ranking 
determines  which  work  functions  are  funded  in  a  given  budget  year.  These 
data  had  been  analyzed  using  a  mainframe  computer.  A  highly  interactive 
process  in  which  decision  makers  request  a  variety  of  rqx)its  based  on  the  data 
in  order  to  assess  the  programmatic  and  Hnancial  impacts  of  alternative 
rankings  is  the  norm,  requiring  intensive  use  of  computer  resources.  The 
majority  of  this  examination  is  done  in  an  intensive  process  during  July,  to 
comply  with  requirements  for  submittals  within  the  budget  cycle. 

The  analysis  was  limited  by  the  software  available  on  the  mainframe,  and  the 
automatic  data  processing  cost  of  doing  even  limited  analysis  was  very  expen¬ 
sive,  about  $15,000  per  cycle.  Due  to  the  heavy  demands  of  the  decision 
makers  for  reporting,  and  the  many  changes  in  work  function  ranking  that  are 
required  to  provide  the  needed  reports,  the  process  was  additionally  limited  in 
terms  of  its  capabilities  to  provide  a  "paper  trafl”  clearly  identifying  the 
various  changes  that  were  made  in  the  course  of  developing  the  final  rankings. 

The  COMB_DSS  was  designed,  initially,  to  replicate  the  reports  that  were 
familiar  to  the  decision  makers,  and  to  provide  a  more  robust  and  accessible 
structure  for  the  analysis  process.  The  system,  as  eventually  developed, 
operated  on  a  high-end  desktop  computer,  allowed  consideration  of  over 
2^  different  scenarios,  and  eliminate  the  majority  of  the  mainframe  process¬ 
ing  costs.  The  ability  to  develop  and  track  different  scenarios  allowed  analysts 
and  decision  makers  to  consider  many  different  possible  funding  levels  for  the 
O&M  budget  The  scenarios  allowed  for  more  analysis  than  was  possible 
under  the  old  system  and  allowed  the  OCR  Division  to  react  quicUy  to  ques¬ 
tions  from  the  many  participants  involved  in  the  budget  process.  Six  versions 
of  the  COMB^DSS  were  delivered  to  the  primary  user  during  the  course  of  the 
project,  with  increasing  speed  of  processing,  flexibility  in  rqmrting,  and  ease 
of  use.  Early  enthusiaan  for  the  system  motivated  the  project  team  to  propose 
the  use  of  the  COMB_DSS  during  the  actual  budget  analysis  during  July- 
August  1992,  rather  than  testing  the  system  alongside  the  old  system.  The 
COMB_DSS  was  used  intensively  and  successfully  for  this  purpose.  An  eval¬ 
uation  of  the  use  of  the  system  in  the  budget  analysis  is  included  as  part  of 
this  report 

The  use  of  the  prototype  COMB_DSS  for  this  past  budget  cycle  was  a  calcu¬ 
lated  risk  that  proved  successful.  The  confidence  provided  by  the  initial  proto¬ 
types  and  the  demonstrated  ability  of  the  project  team  to  quickly  provide  sys¬ 
tem  enhancements  to  meet  newly  defined  or  recognized  user  needs  allowed  the 
research  effort  to  go  forward.  An  additional  factor  of  importance  was  the  deq) 
involvemmt  of  the  primary  user  of  the  system  in  the  development  and  testing, 
providing  important  feedback  and  shortening  the  learning  curve  for  system  use. 
Lessons  learned  during  the  process  can  be  used  to  improve  the  prototype  for 
the  next  budget  cycle.  Work  for  developing  a  simUar  system  for  Division 
offlces  is  underway  in  fiscal  year  1993.  The  use  of  decision  support  systems 
to  support  other  OCR  Division  decisions  will  also  be  explored  forther  under 
the  lOMT  research  program. 


1  Introduction 


Background 

This  research  effort  to  develop  the  Corps  of  Engineers  Operation  and 
Management  Budget  Decision  Support  Syston  (COMB_DSS)  is  part  of  the 
Improvement  of  Operations  and  Management  Techniques  (lOMT)  research 
program.  The  objective  of  the  lOMT  program  is  to  (a)  reduce  costs  whfle 
increasing  the  safety  and  efficiency  of  operations  and  maintenance  (O&M) 
management,  (b)  enhance  the  utility  of  O&M  assets  such  as  locks,  dams,  and 
vessels,  and  (c)  address  the  economic  and  budgetary  issues  in  the  O&M 
function. 

Initially,  the  work  unit  on  the  application  of  decision  support  systons 
(DSS’s)  within  the  Operations,  Construction  and  Readiness  (OCR)  Division, 
Headquarters,  U.S.  Army  Corps  of  Engineers  (HQUSAQE),  was  designed  to 
explore  opportunities  for  DSS,  select  high-priority  opportunities,  and  develop  a 
prototype  to  test  the  effectiveness  of  DSS.  Whoi  the  objectives  of  the  work 
unit  were  explained  to  the  Field  Review  Group  at  the  first  review  meeting  of 
the  lOMT,  the  Field  Review  Group  saw  an  opportunity  to  enhance  the  existing 
O&M  budget  process  by  develqiing  a  DSS  that  would  inqrrove  the  analysis  of 
budget  submissions  for  each  fls^  year  (FY)  budget  The  Field  Review  Group 
suggested  that  the  research  focus  on  devdoping  a  DSS  to  assist  with  decisions 
about  the  budget  process.  The  development  of  a  woriting  DSS  would 
demonstrate  the  usefulness  of  DSS  and  provide  inunediate  beneflts  by  improv¬ 
ing  the  budget  decision  process.  Thus,  the  research  changed  direction  to 
develop  a  DSS  to  assist  with  the  budget  decision  process.  The  starting  point 
for  the  research  was  the  Automated  Budget  System  (ABS). 


The  Budget  Process 

The  OCR  Division  has  instituted  a  fully  developed  budget  process  unda- 
which  O&M  programs  are  funded.  This  process  requires  the  identification  and 
prioritization  of  about  20,000  woric  functions.  Each  year  a  set  of  the  highest 
priority  work  functions  are  sdected  for  funding  comprising  a  total  budget  of 
about  1.5  billion  dollars.  The  projects  most  be  idoitiffed,  budgeted,  and 
prioritized  at  the  District  and  Division  levds,  and  they  are  subsequoitly  com¬ 
bined  by  HQUSACE  into  a  single  data  set  for  further  analysis,  work  function 
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ranking,  and  selection.  The  final  ranked  list  of  work  functions,  as  developed 
by  HQUSACE,  is  incorporated  into  the  final  budget  proposal  for  O&M 
appropriations. 

To  facilitate  the  smooth  transition  of  information  from  the  Districts  through 
Divisions  to  HQUSACE,  the  ABS,  a  management  information  system,  was 
developed  by  the  U.S.  Army  Construction  Engineering  Research  Laboratory 
(CERL).  The  ABS  enables  computerized  collection,  editing,  and  transfer  of 
work  functions  up  the  hierarchy.  The  entire  submission  of  all  work  functions 
is  stored  on  a  mainframe  computer  and  accessed  using  a  network  database 
management  system  (DBMS).  This  DBMS  allows  for  the  production  of  stan¬ 
dard  reports  and  ad  hoc  queries  of  the  work  function  data. 

Once  information  has  been  passed  from  the  Districts,  through  the  Divisions, 
to  the  mainframe  ABS  database,  the  work  functions  must  be  analyzed  to 
decide  which  ones  will  be  included  in  the  current  year  budget  submittal  and 
which  ones  will  fail  to  make  the  cut.  Within  the  budget  process,  HQUSACE 
relies  primarily  on  the  Division  ranks  to  determine  the  priority  of  work  func¬ 
tions.  However,  there  are  national  priorities  that  sometimes  override  the  Divi¬ 
sion  rank.  The  reranking  process  required  tedious  manipulation  of  the 
HQUSACE  rank  for  each  work  function.  There  has  been  no  easy  way  to 
provide  an  audit  trail  of  changes  to  work  function  ranks.  Additionally,  under 
the  budget  process,  all  data  analysis  at  HQUSACE  was  accomplished  on  a 
mainframe  computer.  This  limited  the  flexibility  of  the  analysis  and  resulted 
in  high  computing  costs.  The  process  of  selecting  work  functions  for  funding 
required  tedious  manipulation  of  work  function  ranks.  A  representation  of  the 
original  O&M  budget  process  is  shown  in  Figure  1.  A  better,  more  effective 
process  was  needed.  Tlie  ABS  system  and  its  interaction  with  the  O&M  bud¬ 
get  process  is  described  in  detail  in  Appendix  A. 

Still,  the  existing  budget  system  was  an  excellent  starting  point  for  the 
development  of  a  budget  DSS.  First,  the  database  structure  is  stable,  contains 
the  information  needed  for  the  budget  decision  process,  and  is  extensible  in 
that  additional  information,  such  as  condition  indices,  can  be  added  to  the 
database.  Second,  the  ABS  is  accq}ted  throughout  the  OCR  Division  as  the 
vehicle  for  budget  submissions.  Third,  there  is  a  high  degree  of  institutional 
knowledge  about  the  budget  process  from  the  District  level  through  the 
HQUSACE  level.  Finally,  lOMT  is  investigating  developing  additional  data 
elements  for  each  work  function,  such  as  condition  indicators  and  beneflt/cost 
indicators,  that  will  require  analysis  in  future  budget  cycles.  The  analysis 
process  must  consider  these  new  data  elements. 


Research  Overview 

The  objectives  of  this  study  were  to  develop  a  system  concq)t  and  buUd  a 
functional  prototype  DSS  that  HQUSACE-level  decision  makers  could  use  to 
help  make  decisions  about  the  O&M  budget 
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Figure  1 .  Representation  of  the  original  O&M  budget  process 


The  COMB_DSS  was  initially  designed  to  provide  HQUSACE  with  five 
major  analysis  modules,  as  follows; 

a.  Scenario  Analyst. 

b.  Financial  Analyst 

c.  Ranking  Generators  and  Evaluators. 

<L  Criteria  Analyst 

e.  Statistical  Analyst 

In  the  prototype  system,  only  the  first  three  modules  were  implemented. 
During  the  design  phase,  the  development  team  sought  to  restructure  the 
problem  paradigm  (i.e.,  change  the  way  the  problem  solver  approaches  the 
solution  to  his/her  problem).  A  key  to  this  change  was  the  concept  of  the 
"scenario,”  simply  a  group  of  work  functions,  defined  in  some  fashion,  with  no 
implied  ranking.  By  providing  simple  methods  for  defining  scenarios,  and 
combining  scenarios  into  new  scenarios,  a  "set-oriented"  approach,  in  which 
groups  of  work  functions  are  manipulated,  rather  than  individual  work  func¬ 
tions,  becomes  the  guiding  principle  for  the  analysis.  Some  of  these  "shifts"  in 
thinking  included  (a)  storing  scenarios  versus  performing  ad  hoc  queries  and 
printing  reports,  (b)  reorganizing  the  approach  such  that  changing  work 
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function  ranking  is  done  at  the  end  of  the  process,  rather  than  continually,  as 
with  the  mainframe  system,  and  (c)  developing  the  capability  to  store  derived 
scenarios  as  a  composite,  based  on  Boolean  combinations,  of  existing 
scenarios. 

The  COMB_DSS  was  used  in  the  budget  process  as  a  replacemoit  for  the 
mainframe-based  management,  analysis,  and  reporting  of  work  function  data. 
Once  all  work  functions  were  uploaded  to  the  mainframe  from  the  ABS,  the 
appropriate  data  were  downloaded  into  the  CX>MB_DSS,  where  data  checking, 
scenario  development,  financial  analysis,  and  rank  generation  were  carried  out 
during  intensive  system  use  in  June,  July,  and  August  of  1992.  The  system 
was  used  to  provide  a  variety  of  rqrorts  to  upper  management,  with  extreme 
interactions  in  terms  of  scenario  definition.  Once  final  rankings  were  devel¬ 
oped,  the  information  was  uploaded  to  the  mainframe,  to  be  available  to  Dis¬ 
tricts  and  Divisions  through  the  ABS  process.  The  use  of  the  COMBJDSS  in 
the  budget  process  is  ^own  in  Figure  2. 
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Figure  2.  Representation  of  the  O&M  budget  process  with  the  COMB_DSS 


While  the  COMB_DSS  was  being  used  in  the  budget  year  1994  budget 
submittal,  an  internal  evaluation  process  was  carried  out  in  which  members  of 
the  project  team  examined  how  ttie  COMBJDSS  was  being  used  and  its 
strength  and  weaknesses. 
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Overview  of  Report 


This  chapter  contains  a  background  and  overview  of  the  work  effort, 
including  project  sponsors  and  study  objectives.  Chapter  2  discusses,  in 
generic  terms,  the  DSS  framework  and  system  components,  the  development 
approach,  and  the  steps  typical  of  developing  a  DSS.  Chapter  3  provides 
detail  on  the  development  of  the  COMB^DSS  prototype(s)  in  terms  of  concept, 
design,  and  functional  components.  Chapter  4  contains  an  evaluation  of  the 
prototype  as  used  by  HQUSACE.  Chapter  5  discusses  future  plans  for 
improving  the  COMB_DSS  prototype,  developing  COMB_DSS  capabilities  for 
Divisions  and  Districts,  and  exploring  other  potential  DSS  applications  for  the 
OCR  Division.  Chapter  6  contains  project  results  and  conclusions.  >^pen- 
dix  A  contains  a  detailed  description  of  the  existing  ABS.  There  are  five 
additional  appendixes  that  are  available  separately.  Appendix  B  is  the  Micro- 
ABS/Mainframe  ABS  data  dictionary.  Appendix  C  contains  technical  memos 
and  the  minutes  to  project  team  meetings.  Appendix  D  provides  documenta¬ 
tion  on  the  COMB_DSS  tables  and  structures.  Appendix  E  provides  sample 
COMB_DSS  menus  and  forms.  Appendix  F  contains  COMB_DSS  sample 
reports.  Appendix  G  contains  presentation  materials  used  at  the  Operations 
Chiefs  and  lOMT  Field  Review  Group  meetings  held  in  March  and  April  of 
1992  in  Las  Vegas,  NV,  and  Portland,  OR,  respectively. 
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2  DSS  Framework  and 
Development 


DSS  Components 

Decision  Support  Systems  are  computer-based  information  systems  that 
support  semi-structured  or  unstructured  decisions.  Due  to  the  complexity  of 
these  decisions,  using  proper  models  can  signiHcantly  improve  human  perfor¬ 
mance  by  (a)  facilitating  understanding  about  the  decision  problem,  (b)  exam¬ 
ining  more  alternatives,  and  (c)  enhancing  prediction  capabilities.  Thus,  a 
model  management  system  that  supports  the  development  of  decision  models 
and  their  subsequent  use  is  considered  crucial  to  the  success  of  a  DSS. 

Early  research  in  model  management  considered  models  as  data  or  sub¬ 
routines  and  proposed  that  a  model  managemoit  must  support  model  creation, 
storage,  retrieval,  execution,  and  maintenance.  Latter  research  has  focused  on 
two  issues:  model  base  organization  and  model  representation.  However,  a 
well-developed  DSS  must  have  the  additional  capability  of  selecting  and 
integrating  existing  decision  models  (analysis  components).  Thus,  models 
stored  in  the  analysis  component  of  a  DSS  should  serve  as  (a)  stand-alone 
decision  models,  and  (b)  building  blocks  from  which  more  complex  decision 
models  can  be  buflL  When  a  DSS  contains  these  two  additional  cqtabilities,  it 
can  better  support  decision  makers  by  formulating  ad  hoc  models  to  meet 
unanticipated  requirements  quickly. 

Typical  DSS’s  contain  four  major  components,  as  shown  in  Figure  3.  The 
database  component  is  designed  to  facflitate  storage  and  retrieval  of  model 
selection  criteria  and  model  results.  The  database  design  should  consider 
(a)  selection  criteria  required  of  the  analysis  component,  (b)  the  speed  with 
which  required  data  can  be  retrieved,  and  (c)  how  outyut  database  tables 
should  be  created  to  properly  rq)resent,  integrate,  and  report  information 
resulting  from  analysis. 

The  user-interface  design  should  be  intuitive  in  terms  of  menu  structure  and 
forms  access.  The  menus  should  allow  the  user  to  follow  a  logical  progression 
of  information  managemoit,  nKxiel  selection,  analysis,  and  results  processing. 
Forms  design  should  focus  on  providing  the  user  with  a  window  to  the 
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database.  The  layout  of  forms  or  "database  windows*  should  consider  data 
most  commonly  required  by  the  DSS  analysis  models. 

The  analysis  tools  should  maintain  a  budding  block  capability,  as  described 
previously,  and  should  focus  on  the  types  of  decisions  that  will  be  made  from 
DSS  analysis.  Furthomore,  the  analysis  tools  must  also  be  flexible  in  nature, 
therd)y  allowing  ad  hoc  queries  reaching  the  bounds  of  the  model  domain  to 
be  properiy  answered.  Finally,  the  analysis  tools  must  be  octensible  and  com¬ 
prehensive  so  that  they  can  be  easily  adapted  to  a  potentially  changing  problem 
domain. 


Development  Approach 

A  typical  development  q)proach  consists  of  (a)  identifying  a  well-defined 
problem  domain  for  which  a  DSS  can  be  developed,  (b)  identifying  a  develop¬ 
ment  team  with  the  technical  expCTtise  required  to  addr^  inevitable  DSS 
hardware/software  issues,  as  well  as  a  bacl^round  in  modeling  qqttoaches  that 
will  provide  solutions  to  the  problem  domain,  and  (c)  finding  Technical  Moni¬ 
tors  (Climts)  who  are  subject  matter  e}q)erts  and  who  constantly  require  solu¬ 
tions,  under  varying  domain  q[)ecifications,  within  the  problem  domain. 
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DSS  Development  Methodology 


DSS  development  typically  follows  a  logical  and  generic  progression  of 
events.  There  are  typically  four  components: 

a.  System  concept.  The  system  concept  specifies  the  requirements  for  the 
DSS,  describing  how  the  DSS  will  assist  in  meeting  the  requirements, 
and  serves  as  a  way  to  communicate  the  "vision”  of  the  DSS  to  decision 
makers.  The  system  concq>t  report  should  address  the  following  topics: 
User  Requirements;  Feasibility  Constraint  Assessment;  Development  of  a 
Functional  Model;  Selection  of  Methods;  Assessment  of  Appropriate 
Software  and  Hardware;  Development  of  Methodologies  for  System 
Packaging,  Transfer,  Documentation,  Maintenance,  Support,  and 
Evaluation. 

b.  System  desipu  The  system  design  is  a  "blueprint"  for  the  DSS,  specify¬ 
ing  the  hardware  and  software  to  be  used  and  outlining  the  stq>s  to  be 
taken  to  build  the  system.  The  system  design  report  documents  the 
system  specifications,  contains  system  documentation,  and  provides  a 
testing  and  evaluation  plan. 

c.  Implementation.  Although  DSS  implementation  can  be  managed  with  a 
variety  of  methods,  a  cyclic  approach  is  desired,  in  which  the  design 
team  develops  "real"  prototypes,  evaluates  them,  and  returns  to  concept 
for  another  iteration.  This  approach  is  superior  to  most  others  because 
(1)  proof-of-concq)t  is  veriHed,  (2)  an  evolved  prototype  exists  when  the 
project  is  complete,  (3)  the  review  and  testing  feedback  loop  is  com¬ 
plete,  and  (4)  functional  risk  is  minimized  in  the  evaluation  phase. 
Implementation  should  include  a  modular  or  "building  block"  approach 
to  functional  components.  In  this  fashion,  functional  components  can  be 
developed  and  tested  quickly  and  concurrently  by  different  team  mem¬ 
bers.  Rapid  prototyping  will  quickly  determine  the  success  or  failure  of 
a  DSS  project 

d.  Evaluation.  Under  the  iterative  prototype  development  approach,  system 
evaluation  and  resulting  improvements  are  accomplished  in  a  stq>-wise 
fashion.  Thus,  upon  project  closure,  the  design  team  and  clients  are 
usually  aligned  and  agree  with  the  functional  aspects  of  the  final  DSS 
product  That  is,  functional  risk  is  minimized  or  resolved  in  the  course 
of  prototype  development 

The  process  is  not  linear,  but  rather  "looping."  Between  concept  and  design 
may  come  iterative  prototyping,  which  typically  requires  the  design  team  to 
return,  to  some  degree,  to  concqjt  By  allowing  users  to  interact  with  a  series 
of  "real"  but  limited  versions  of  the  system,  this  approach  minimizes  the  risk 
associated  with  having  the  Hnal  system  fall  short  of  expectations.  During 
implementation  and  evaluatton,  additional  features  may  be  desired,  or  new 
techniques  and  approaches  may  evolve,  which  serve  to  change  the  concept  and 
design  qrecifications. 
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This  iterative,  rapid  prototyping  approach  was  followed  in  develqpnient  of 
the  CX)MB_DSS,  and  proved  to  be  very  valuable.  In  particular,  the  rapid 
prototyping  approach  provided  a  strong  framework  for  development  and 
critiques,  as  there  is  always  something  "real*  to  work  with  and  evaluate. 
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3  COMB_DSS  Prototype 
Development 


Concept 

Following  the  general  outline  of  DSS  development  practices,  with  emphasis 
on  prototype  devdopm«it,  COMB_psS  efforts  began  with  a  requiranents 
analysis,  in  which  the  project  team  examined  (a)  the  existing  AK  database, 

(b)  the  current  ABS  budget  cycle  and  information  flow,  and  (c)  the  types  of 
analyses  performed  by  HQU^CE.  The  design  team  found  the  ABS,  written 
and  maintained  by  CERL,  to  be  a  workable  and  concise  management  informa¬ 
tion  system.  Thus,  it  was  concluded  that  the  development  of  iterative  proto¬ 
types,  in  which  modding,  database,  and  usn-interface  componmts  would 
evolve  with  each  iteration,  was  the  most  logical  way  to  proceed. 

The  ABS  system  was  examined  to  determine  its  role  in  the  O&M  budget 
process,  and  a  detailed  description  can  be  found  in  Appendix  A.  The  ABS 
results  in  a  set  of  worit  fimctions,  defined  and  ranked  by  Districts  and  Divi¬ 
sions,  residing  on  a  mainframe  computer.  These  woric  functions  are  then 
analyzed  and  ranked  by  HQUSACE  to  provide  a  complete  ordering  of  all  woric 
functions.  This  allows  for  a  clear  detomination  of  the  work  functions  that  vrill 
be  funded  as  the  actual  budget  is  finally  set  The  ranking  process,  carried  out 
prior  to  this  year  on  a  mainframe,  is  a^y,  cumbersome,  and  labor-intensive. 
Based  on  the  nature  of  the  pioblm,  HQUSACE’s  desire  to  improve  the  pro¬ 
cess  of  handling  ABS  data,  the  decision  support  activities  were  directed  to  this 
end  (i.e.,  posqirocessing  of  the  ABS  data  for  puqx>ses  of  ranking  and 
evaluation). 

The  analyst  in  the  OCR  Division  re^nsible  for  technically  supporting  the 
annual  worit  function  rankings  served  as  the  key  "client  representative,”  pro¬ 
viding  information  as  to  the  nature  of  the  problem,  ongoing  evaluation,  and 
testing  and  use  of  the  ptototype(s).  Additional  review  and  guidance  were  pro¬ 
vided  by  other  membm  of  the  project  team.  The  particular  approach  selected 
for  system  development  was  that  of  iterative  prototype  devdopment  and  refine¬ 
ment  In  this  method,  a  series  of  prototype  systems  are  generated  and  re¬ 
viewed  by  the  client  Each  system  provides  inoeasing  capabflities,  as  guided 
by  the  reactions  and  results  of  the  previous  prototype.  The  approach  demands 
a  good  deal  of  interaction  between  the  devdopers  and  the  client,  and  rq>id 
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response  of  both  parties.  The  actual  project  generated  some  six  prototype 
versions.  Changes  to  the  prototypes  were  extensively  documented  in  internal 
technical  memos. 

After  an  examination  of  the  existing  ABS  cycle  and  software,  budget  guid¬ 
ance  circulars,  and  the  information  requirements  of  HQUSACE,  the  design 
team  evolved  a  structure  for  the  COMB_DSS  based  on  the  organizing  concept 
of  "scenarios."  A  scenario  is  simply  a  set  of  criteria  that  serve  to  select  a  sub¬ 
set  of  work  functions  from  all  available  work  functions.  An  exaiiq)le  scenario 
would  be  "all  navigation  work  functions  in  ORD."  This  criterion  can  be 
applied  to  the  information  stored  about  each  work  function  (from  the  ABS)  to 
determine  which  work  functions  meet  the  scmario  critnion,  and  thus  are  in  the 
scenario.  Each  scenario  thus  iiiq>lies  a  set  of  work  functions,  an  associated 
cost  for  the  scenario,  and  a  distribution  of  that  cost  by  District,  Division, 
project,  etc. 

The  scenario  concept  allows  for  redesigning  the  approach  to  work  function 
ranking  away  from  individual  work  functions  and  toward  thinking  of  work 
function  groups.  Under  the  scenario  concq)t,  assigning  ranks  to  work  func¬ 
tions  is  the  last  step  in  the  process.  Prior  to  that  time,  woric  functions  are 
grouped  into  scenarios  and  the  flnancial  implications  of  individual  scenarios 
and  combinations  of  scenarios  are  compared  Whoi  ranking  under  the  sce¬ 
nario  concept,  whole  scenarios  are  given  prefmntial  ranks.  In  effect,  when 
work  functions  are  "moved  up  or  down,"  they  are  moved  up  or  down  in 
groups.  A  two-step  ranking  process  involves  frrst  ranking  the  scenarios,  then 
goierating  ranks  at  the  work  function  level  based  on  defined  algorithms.  The 
consequences  of  ranking  can  then  be  evaluated  in  financial  terms  and  in  terms 
of  disrupting  the  rank  order  preference  of  work  functions  within  a  Division. 

The  scenario  approach  is  in  contrast  to  the  prior  method,  in  which  all  worit 
functions  are  reranked  whenever  it  is  necessary  to  develop  a  new  set  of  finan¬ 
cial  reports  based  on  different  criteria.  Drawbacks  of  the  prior  method  include 
(a)  a  high  degree  of  labor  intensiveness,  (b)  diRiculty  in  maintaining  a  paper 
trail  or  history  to  show  what  had  beat  done  previously,  (c)  high  mainframe 
computer  costs,  and  (d)  lack  of  flexibflity. 

The  COMB_DSS  was  structured  with  Hve  modeling  components,  in  order 
of  priority  desired  for  implementation,  as  follows: 

a.  Scenario  analyst  Given  a  ranking  range  and  additional  selection  criteria 
(e.g.,  appropriation  code),  determine  whether  a  particular  work  function 
is  in  or  out  of  a  scoiario. 

b.  Financial  analyst  How  does  a  given  scenario  and  dollar  amount  result 
in  distributing  dollars  to  Districts  and  Divisions  among  cat^ories, 
classes,  feature  cost  codes,  etc.?  How  do  scenarios  compare  in  terms  of 
these  distributions  of  costs? 

c.  Rank  generator.  Givoi  a  set  of  scenarios,  generate  a  rank  for  each  work 
function  and  evaluate  the  resultant  ranking. 
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d.  Criteria  analyst.  Given  criteria  that  describe  a  function,  descriptive 
rq)orts  are  generated.  (It  is  assumed  that  additional  criteria  will  become 
available  in  the  future,  as  more  research  is  conducted,  e.g.,  condition 
index.) 

e.  Statistical  analyst  Perform  "discovery”  to  look  for  relationships  in  the 
database,  generate  overall  statistical  measures  from  the  database. 

The  scenario  analyst  was  identiHed  by  HQUSACE  as  the  most  urgently 
needed  capability,  and  this  was  addressed  first  in  the  prototype  development 
The  final  CX)MB_DSS  version  includes  the  scenario  analyst,  rank  generator, 
and  financial  analyst  modules.  The  critoia  analyst  was  not  developed  because 
additional  criteria,  such  as  condition  index  and  benefit-cost  ratios,  were  evalu¬ 
ated  in  the  scenarios.  When  additional  criteria  are  added  to  the  ABS  database, 
the  criteria  analyst  will  be  added  to  the  COMB_DSS.  The  statistical  analyst 
was  not  considered  necessary  during  the  prototype  testing. 


Design 

The  COMB_DSS  was  implemented  for  a  personal  computer-based  386  or 
better  computer  system,  using  the  DOS  q>erating  system  and  the  R:BASE 
relational  database  management  ^stem  (^BMS).  Versions  3.1b  through  4.0 
of  R:BASE  were  used  as  they  were  rdeased  l;y  the  vendor.  Although 
ORACLE  Version  6.0  was  evaluated,  R:BASE  was  used  because  of  capabili¬ 
ties  that  allow  rapid  prototyping.  The  use  of  R;BASE  will  readily  facilitate 
system  transfer  to  ORACLE  under  DOS  or  another  platform  with  operating 
environments  that  support  SQL. 

As  noted  previously,  the  scenario  concqrt  was  at  the  heart  of  the  new 
approach  to  analysis  and  ranking.  In  keq)ing  with  the  relational  database 
structure  underlying  the  DSS,  the  definition  of  a  scenario  is  stored  in  database 
tables,  and  the  results  of  scenario  evaluation  are  likewise  stored  in  tables. 

The  key  table  of  the  COMB^DSS  is  the  WORKFUNC  table,  containing 
information  on  each  of  the  individual  work  functions,  including  District, 
Division,  CWIS  number.  District  and  Division  rank,  initial  HQUSACE  rank, 
descriptions,  project  class,  and  feature  cost  code.  This  table  is  downloaded, 
essentially  as  is,  from  the  mainframe  ABS,  and  reflects  the  input  of  Districts 
and  Divisions  and  the  initial  ranking,  as  develq)ed  by  HQUSACE,  based  on 
the  Division  ranks.  Information  stored  in  this  table  is  not  changed,  through  the 
entire  process,  until  the  final  assignment  of  revised  ranks. 

Three  methods  of  defining  scenarios  wm  developed: 

a.  Primary  scenarios.  Defined  as  a  set  of  critoia  that  operate  as  a 
selection  mechanism  for  worit  functions  stored  in  the  WORKFUNC 
table,  and  ento-ed  through  a  foims-oriented  interface. 
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b.  Composite  scenarios.  Boolean  combinations  of  existing  scenarios,  i.e., 
the  unimi  of  all  of  the  worit  functions  in  a  set  of  scenarios,  or  the 
intersection  of  the  work  functions  in  two  scenarios  (those  work  functions 
that  are  conuncm  to  both  scenarios.) 

c.  SQL  scenarios.  Scenarios  deflned  by  applying  a  user-deflned  query 
using  SQL  to  the  WORKFUNC  table. 

The  general  approach  to  scenario  development  is  as  follows: 

a.  Create  a  scenario  through  one  of  these  three  methods. 

b.  Generate  the  set  of  all  work  functions  that  fit  the  scenario  critoia  as  a 
temporary  table  [the  TEMPSCEN  table]  containing  only  those  work 
functions  that  are  in  the  scenario. 

c.  Evaluate  the  temporary  table,  from  a  financial  point  of  view,  in  terms  of 
the  cost  breakout  by  District  and  Division,  Project  Qass,  and  Feature 
Cost  Code. 

d.  Store,  if  desired,  the  set  of  work  functions  in  the  scenario  as  a 
"permanent”  scenario  for  latm  recall  and  for  use  in  building  composite 
scenarios.  When  a  scenario  is  stored,  the  flnancial  summary  data  for  the 
scenario,  by  Division,  Qass,  and  Feature  Cost  Code  are  also  stored  in 
tables,  so  that  corrqrarisons  can  be  made  without  recalculating  financial 
statistics. 

As  noted  previously,  the  scenario  approach  b  new.  Initially,  the  COMB_DSS 
was  designed  to  hajidle  a  maximum  of  64  scenarios,  based  on  user  input 
During  the  course  of  the  effort,  this  number  was  expanded,  first  to  128 
scenarios  and  finally  to  256  scenarios  as  more  and  more  use  was  made  of  the 
composite  scenarios. 

As  increasing  use  was  made  of  this  iqrproach,  the  need  to  rapidly  generate, 
evaluate,  and  store  multiple  scenarios  increased.  Accordingly,  as  the  proto¬ 
types  evolved,  more  efficient  methods  for  handling  the  scenario  generation 
were  developed,  but  the  basic  concept  of  this  flow  was  maintained. 


Scenario  analyat 

The  COMB_DSS  contains  a  "Manage  Scenarios”  capabflity,  in  which  pri¬ 
mary,  SQL,  and  conqxraite  scenarios  can  be  entered,  edited,  copied,  delet^ 
and  renamed.  The  primary  scenario  selection  criteria  include  appn^riation 
code;  a  range  of  HQUSACE  ranks;  a  range  of  ouq>ut  measures  (to  become 
condition  indices);  two  user-added  ranges  that  are  not  currently  used;  minimum 
cost;  cumulative  cost;  inclusive  divisions;  inclusive  classes;  and,  include/ 
exdude  capabUities  for  CWIS  numbers,  HQUSACE  ranks,  and  feature  cost 
codes.  A  fbrms-oriaited  interface  allows  for  easy  qiecification  of  these 
criteria. 
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A  composite  scenario  is,  as  noted  previously,  an  integration  of  primary 
scenarios,  built  through  an  intersect,  union,  or  subtraction  process.  A  U 
(union)  scenario  will  provide  the  union  of  work  functions  specified  (i.e.,  any 
work  function  in  any  U  scenario  is  in  the  composite).  An  /  (intersect)  scenario 
gives  the  intersection  of  the  7  work  functions  (i.e.,  the  work  function  must  be 
present  in  all  /  work  functions  to  be  included  in  the  composite).  The  S  sce¬ 
nario  subtracts  work  functions  in  the  5  scenarios  from  the  work  functions  in 
the  /  scenarios.  The  5  scenario  cannot  be  combined  with  the  U  scenarios,  only 
with  the  I  scenarios,  and  /  and  U  are  also  mutually  exclusive.  When  5  and  I 
are  processed  jointly,  the  I  scenarios  are  processed  first,  and  then  the  S 
scenarios  are  subtracted. 

The  COMB_DSS  also  contains  a  feature  that  allows  the  user  to  build  an 
ad  hoc  SQL  scenario.  This  allows  consideration  of  selection  criteria  that  are 
not  in  the  current  primary  selection  criteria  forms.  In  actual  use,  this  feature 
was  not  utilized  extensively. 


Financial  analyst 

Financial  analysis  takes  place  at  three  different  levels:  by  comparison  of 
scenarios  Corps-wide;  by  detail  within  a  Division;  and  by  work  function  within 
a  scenario.  Hie  first  two  levels  allow  for  comparison  of  up  to  seven  scenarios, 
in  terms  of  dollar  cost  breakouts  by  Division,  by  Feature  Cost  Code  (at  prefix 
or  detail  level),  and  by  Project  Qass.  This  allows  for  rapid  comparison  of  the 
"distributional"  impacts  of  various  scenarios.  Detailed  rqxirts  for  a  given 
scenario  display  information  for  each  of  the  work  functions  in  the  scenario. 

The  format  of  these  rqiorts  was  designed,  based  on  client  preferences,  to  be  as 
close  as  possible  to  the  prior,  mainframe-generated  rqxirts,  in  order  to  present 
results  to  decision  makers  in  a  familiar  format  It  should  be  noted  that, 
although  graphical  display  capabQities  are  generally  thought  to  be  an  integral 
part  of  a  DSS,  in  the  current  case,  client  orientation  was  much  more  strongly 
toward  famOiar  numerical  reports.  The  use  of  the  roll-up  tables  that  stored 
flnancial  summaries  for  each  scenario  made  generation  of  the  required  reports 
much  faster.  An  additional  type  of  financial  analysis  is  also  provided,  post¬ 
ranking,  to  evaluate  the  consequences  of  ranking  scenarios. 


Rank  generator 

The  prior  ranking  method  involved  continual  assignment  of  HQUSACE 
ranks  at  the  work  function  level.  Under  the  COMB_DSS  approach,  ranking  is 
approached  at  the  scenario  level.  The  user  assigns  "scores"  to  each  scenario, 
reflecting  the  desirability  of  the  scenario,  in  terms  of  funding,  with  a  lower 
score  rqiresenting  a  more  desirable  situation.  Once  scores  are  assigned  at  the 
scenario  level,  a  process  exists  to  assign  scores  at  the  woric  function  level. 
Given  the  nature  of  scenarios,  a  work  function  can  be  in  many  scenarios.  A 
variety  of  algorithms  w^e  explored  to  determine  how  to  assign  a  work  func¬ 
tion  score  based  on  scenario  scores,  including  weighting  scenario  scores, 
summing  scenario  scores,  or  using  the  best  score.  The  "best  score"  algorithm 
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simply  looks  at  all  of  the  scenario  scores  for  all  scenarios  in  which  the  work 
function  is  present,  and  assigns  to  the  work  function  the  best  (in  this  case  the 
lowest)  of  these  scores. 

The  process  resmzs  in  assignment  of  a  score  to  each  work  function,  but 
these  scores  are  not  necessarily  unique.  The  ultimate  desire  is  a  unique  rank¬ 
ing  number  for  each  woik  function,  correlating  to  a  funding  level.  Again,  a 
number  of  different  algorithms  were  explored  to  assign  unique  ranks.  The 
overall  desire  is  to  rank  all  work  functions  that  share  the  same  score,  in  order. 
The  eventually  adopted  method,  based  on  user  preference,  was  to  use  the  origi¬ 
nal  HQUSAOE  rank  (based  on  Division  and  District  assigned  ranks)  to  order 
work  functions  within  a  score  level,  leading  to  a  unique  rank. 

Financial  analysis  components  allow  for  determination  of  total  costs  based 
on  scenario  scores,  so  that  the  dollar  consequences  of  assigning  any  set  of 
scores  can  be  reviewed. 

The  rank  generation  process  provides  a  good  deal  of  flexibility,  and  allows 
for  a  number  of  options  in  developing  ranks.  Given  the  time  constraints  for 
development  of  the  recommended  budget  submittal,  the  rank  gmeration  capa¬ 
bilities  of  the  COMB^DSS  were  not  fully  explored,  as  primary  emphasis  was 
devoted  to  scenario  generation  and  evaluation. 


Implementation 

The  COMB^DSS  Hnal  prototype  was  developed  in  R:BASE  4.0,  using 
DOS  version  5.0  as  the  primary  operating  system,  and  installed  at  HQUSACE 
on  a  Compaq  486/50L  microcoiiq)uter.  The  Compaq  is  a  server  machine  on  a 
Novell  3.11  Local  Area  Network  and  maintains  connectivity  with  workstations 
through  IBM  token-rings  and  twisted-pair  coaxial  connections. 

Six  prototypes  were  developed.  The  first  prototype  approach  was  far  off 
the  mark,  and  was  abandoned.  The  next  five  prototypes  were  evolutionary 
developments,  with  changes  oriented  primarily  toward  q)eeid,  ease  of  use,  and 
additional  features,  but  with  the  basic  framework  remaining  intact  A  major 
improvement,  in  moving  from  prototype  2  to  prototype  3,  involved  develop¬ 
ment  of  an  external  processing  procedure  for  storing  the  status  of  a  work  func¬ 
tion  in  a  scenario.  The  initial,  relational  implementation  proved  too  slow  and 
cumbersome. 

A  work  function’s  status  in  a  given  scenario  can  be  stored  in  a  single  bit,  as 
a  1  (work  function  is  present  in  scenario)  or  0  (woik  function  not  in  scenario). 
This  suggested  the  use  of  bit  fields  as  a  compact  method  of  data  storage  for 
this  information.  Conceptually,  a  table  could  be  created,  with  a  row  for  each 
work  function  and  columns  representing  the  1/0  flag,  for  as  many  columns  as 
the  maximum  etqtected  numb^  of  scenarios.  This  approach  was  irr^rlemented 
through  the  use  of  a  set  of  custom-writtoi  C  programs  that  man^ulate  this 
table  (referred  to  within  the  COMB_DSS  as  the  BitMap  flle).  This  provided  a 
dramatic  improvonoit  in  processing  capabilities. 
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Other  features  developed  during  the  course  of  iterative  protot)rping  include 
the  financial  analyst;  rank  generators  (sets  of  C  programs  executed  external  to 
R:BASE);  additional  reporting  capabilities;  logical  checks;  initial  reports  that 
apply  to  annual  imports  from  the  ABS;  and  enhanced  ease-of-use  features  such 
as  more  descriptive  keystroke/screen  information,  pick-lists,  generation  of 
multiple  scenarios,  and  system  utilities. 
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4  Evaluation  of  Prototype 


Technical  Performance 

The  COMB_DSS  prototype  was  applied  and  tested  at  HQUSACE  over  a 
S-week  period  commencing  27  July  1992.  It  was  installed  on  a  Compaq 
486/50L  microcomputer  running  Novell  3.11  as  the  primary  local  area  net¬ 
work.  Access  to  internet  and  the  Civil  Works  mainframe  information  base, 
located  on  the  Washington  Computer  Center  (WCC),  was  accomplished  using 
the  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP)  inherit  in  File 
Transfer  Protocol  (FTP)  version  2.0  J.  The  Civil  Works  information  database, 
residing  on  the  WCC  mainframe,  is  accessed,  maintained,  and  extracted  using 
the  RAMIS  fourth-generation  RDBMS. 

The  COMBJDSS  prototype  was  developed  using  RrBASE  version  4.0,  a 
product  of  Microrim,  Inc.,  and  various  C  programs  written  by  the  developm«it 
team.  The  projected  size  of  the  extracted  database  on  the  WCC  mainframe  is 
sqrproximately  22  MB.  This  extract  file  was  transferred  from  the  WCC  main- 
fr^e  to  the  Compaq  486/50L  in  1.S  hours  using  FTP  running  TCP/IP  on  the 
Internet  In  contrast,  it  would  have  taken  8  hours  using  a  9600  V32  modon 
to  transfer  the  same  extract  flle. 

The  COMBJDSS  did  accomplish  the  stated  goal  of  supporting  HQUSACE 
during  the  O&M  budget  submittal  by  (a)  increasing  the  number  of  scenarios 
generated  in  the  limited  reaction  time,  and  (b)  providing  a  cost-effective  alter¬ 
native  to  ad  hoc  query  and  reporting  procedures  typically  performed  on  the 
mainframe  ^stem  using  RAMIS.  The  COMB_DSS  concert  Ht  very  well  in 
the  HQUSACE  Civil  Works  environment  and  provided  more  information  for 
decision  making  than  had  been  available  in  previous  years.  The  primary  user 
of  the  COMB_DSS  ^stem  stated  that  the  system  is  significantly  better  and 
more  cost-effective  than  what  had  been  used  in  previous  years.  The  capabUity 
of  returning  to  stored  scenarios  and  running  than  if  necessary  was  a  great 
improvement  over  previous  capabilities. 

Ovoall,  the  operation  of  the  COMB_DSS  system  was  reasonably  intuitive. 
There  was  some  discussion  on  the  use  of  function  keys  and  the  consistency 
with  which  they  are  used  in  different  areas  of  the  system.  The  primary  con¬ 
cern  was  undostanding  the  process  of  scenario  building  and  how  composite 
scenarios  were  derived  from  other  scenarios.  The  end-user  must  be  cautioned 
that  scenarios  dependent  on  other  scenarios  must  be  rebuilt  when  those 
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dqjcndencies  change.  The  speed  of  the  CX)MB_DSS  was  sufflcient  to  provide 
the  results  of  the  scenarios  to  high-level  decision  makers  in  a  timely  manner. 

In  addition  the  capability  to  evaluate  and  store  multiple  scenarios  greatly 
improved  productivity  and  ease  of  use,  when  compared  to  the  "old"  way  of 
doing  things. 

The  cost  savings  achieved  using  the  COMB_DSS  is  difficult  to  evaluate. 
Last  year’s  WCC  mainframe  costs,  incurred  during  scenario  processing,  are 
estimated  at  $11,116.58.  It  should  be  noted,  however,  that  the  prototype  test 
was  more  scenario  intensive  this  year  than  in  previous  years.  If  all  scenarios 
built  on  the  COMB_DSS  had  been  built  on  the  WCX  mainframe,  it  is  esti¬ 
mated  that  the  cost  would  have  been  at  least  three  times  the  cost  incurred  in 
previous  years.  Thus,  the  COMB^DSS  system  appears  to  be  a  cost-effective 
solution. 

The  COMB_DSS  system  was  designed  to  be  modular  such  that  needed 
system  capabilities  that  were  unforeseen  or  overlooked  could  be  readily  imple¬ 
mented.  An  upgrade  from  R:BASE  3.1(c)  to  RrBASE  4.0  required  no  systm 
changes.  Requests  from  upper  level  managers  for  changes  in  report  formats 
were  quickly  addressed  by  developers  of  the  COMB_DSS  in  a  very  short  time 
period.  The  CX>MB_DSS  accommodates  the  existing  way  of  doing  things  at 
HQUSACE  and  affords  the  opportunity  to  change  the  process  for  improved 
productivity  and  cost  effectiveness. 

Although  the  COMB^DSS  system  accomplf  ed  its  objective,  problems 
were  encountered  during  implementation.  Ihe  most  prevalent  concern  is  the 
reliability  of  R:BASE;  for  the  COMB_DSS  da  w'^^se  was  damaged  two  times 
and  had  to  be  reconstructed  each  time.  It  is  not  «lear  what  caused  the  database 
damage,  but  clearly,  it  occurred  during  normal  use  of  the  COMB_DSS.  The 
upgrade  from  R:BASE  3.1(c)  to  4.0  seemed  to  alleviate  the  problem.  A 
backup  capability  was  provided  with  CX}MB_DSS  to  ensure  the  restoration  of 
the  RBASE  .RBF  files.  However,  the  non-.RBF  BitMap  file  should  have  also 
been  included  in  the  backup  process.  During  the  prototype  test,  the  BitMap 
file  was  accidentally  overwritten  after  the  backup  procedure  had  been  per¬ 
formed.  All  the  scenarios  had  to  be  rerun,  which  consumed  the  better  part  of 
one  workday. 

Almost  all  of  the  features  of  the  COMB_DSS  system  were  thoroughly  used 
at  one  time  or  another  during  the  prototype  test.  The  primary  capability  of 
ranking  scenarios  was  not  used  in  the  prototype  test  as  anticipate!  by  the 
development  team.  In  an  effort  to  accomplish  ranking  as  it  was  accomplished 
in  previous  years,  the  ranking  feature  of  the  COMB_DSS  was  based  on  recom¬ 
mended  budget  scenario  only.  The  COMB_DSS  has  the  capacity  to  rerank 
work  functions  based  on  Division  rank,  but  decision  makers  chose  to  use 
HQUSACE  rank  when  finalizing  the  recommended  budget  scenario. 
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Organizational  Issues 


Effective  use  of  the  CX)MB_DSS  requires  a  working  insUtutionaJ  knowl¬ 
edge  of  policy  and  procedure  at  Civil  Works  HQUSACE  level.  The 
COMB_DSS  system  provides  the  capability  necessary  to  make  decisions  dur¬ 
ing  the  O&M  budget  allocation  process.  The  overall  concq>t  was  clear  to  the 
end-user,  but  there  was  some  ambiguity  with  regard  to  formulation  of 
scenarios  and  how  scenarios  are  related.  Strategies  for  scoiario  formulation 
need  to  be  identified  before  using  the  COMB_DSS.  Even  for  an  experienc 
user,  the  COMB_DSS  requires  a  certain  degree  of  instruction  and  training, 
useful  feature  would  be  to  indicate  which  scenarios  are  primary  and  which 
part  of  a  composite  when  producing  scenario  reports. 


The  COMB_DSS  training  was  conducted  at  HQUSACE  just  prior  to  the 
applying  the  evolved  prototype  to  the  1994  O&M  budget  submittal.  During 
preliminary  training  of  the  COMB_DSS,  several  changes  were  identified  and 
corrected  within  the  ^ace  of  a  day.  It  was  not  possible  to  train  the 
COMB_DSS  end-user  in  detail  given  the  approaching  budget  allocation  pro¬ 
cess.  Rather,  attention  was  focused  on  comprehensive  hands-on  use  of  the 
COMB_DSS  system  and  strategies  for  using  COMB_DSS  effectively. 

The  COM  B_DSS  prototype  system  has  demonstrated  responsiveness  to 
HQUSACE  requirements  in  sevo^al  ways.  The  COMB_DSS  allowed 
HQUSACE  to  perform  budget  submittals  in  a  manner  similar  to  that  of  pre¬ 
vious  years  while  remaining  flexible  enough  to  adapt  to  on-the-^t  changes. 
The  COMB_DSS,  by  design,  does  provide  alternative  methods  of  accomplish¬ 
ing  the  budget  allocation  process,  which  may  be  utilized  in  the  next  budget 
cycle.  As  mentioned  previously,  the  formulation  of  the  budget  submittal  was 
more  scenario  intensive  this  year  than  in  previous  years.  Thus,  the 
COMB_DSS  demonstrated  the  capability  to  handle  the  information  load  quite 
effectively  while  reducing  the  cost  of  doing  business  dramatically. 
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5  Future  Directions 


Prototype  Improvements 

Although  accounted  for  in  design,  the  CX}MB_DSS  wfll  need  to  be  modi¬ 
fied  to  acconunodate  additional  criteria  analysis,  such  that  ongoing  research 
and  related  mathematical  models  (e.g.,  incremental  analysis,  where  a  service¬ 
ability  index  is  being  developed)  that  support  ways  of  comparing  two  disjoint 
classes  of  work  can  be  implemented  with  all  necessary  data. 

^)eed  improvements  will  likely  be  a  function  of  R:BASE  (or  other 
RDBMS  environment  that  supports  SQL)  inqrrovements  and  oihanced  com¬ 
puter  speeds.  Other  improvements  will  include  consistency  in  k^stioke 
handling,  on-screen  information,  a  context-sensitive  help  system,  and  additional 
analysis  tools. 

The  initial  design  called  for  grqrhic  reporting  capabflities,  but  budgetary 
constraints,  given  the  workload  and  the  fact  that  CX)MB_DSS  became  "real”  in 
later  prototype  stages,  preonpted  their  inqrlonaitation.  Graphics,  implemented 
through  a  pre-existing  software  package,  RtBASE  enhancements,  or  custom 
development,  are  highly  desirable  for  CX)MB_DSS  stage  n. 

Additional  analysis  capabilities  such  as  a  statistical  analyzer  that  affords  the 
user  meaningful  information  through  data  exploration  and  trend  examination 
(e.g.,  comparison  to  historic  data)  are  desirable  in  the  next  phase  of 
development 

Given  the  desired  OOMB_DSS  irrqrrovements,  R:BASE  will  need  to  be 
reevaluated  to  determine  if  its  current  curabilities  are  sufficimt  The  question 
of  porting  the  COMB_DSS  to  ORACLE  or  some  other  RDBMS  envirorunent 
on  a  mainframe  or  UNDC  workstation  will  need  to  be  further  examined. 


Distributed  COMB.DSS 

There  exists  the  possibility  of  providing  the  Corps  Districts  and  Divisions 
with  a  distributed  version  of  COMB.DSS.  This  would  require  an  raramination 
of  how  various  Districts/Divisions  are  performing  budget  submittals  on  the 
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micro-ABS.  Do  they  perform  scenario  analysis?  With  what  tools?  Given  the 
complexity  of  the  COMB_DSS  and  the  knowledge  of  the  end-user,  a  distrib¬ 
uted  system  might  well  require  significant  changes  in  design.  However,  a 
distributed  COMB_DSS  will  provide  both  HQUSACE  and  Divisions  with 
more  reliable  data,  and  perhaps  a  lighter  workload,  by  distributing  the 
decision-making  process  to  those  closer  to  the  actual  work. 


Other  Potential  DSS  Applications 

The  COM B_DSS  is  a  useful  tool  that  allows  HQUSACE  to  examine  and 
analyze  budget  submittals  by  Divisions.  A  similar  capability  that  addresses  the 
expenditure  of  funds  provided  via  the  O&M  appropriation  is  needed  to  provide 
a  total  picture  for  OCR  managers  about  the  disposition  of  funds.  The  database 
for  such  a  DSS  would  be  provided  by  the  Corps  of  Engineer  Management 
Information  System  (COEMIS)  or  the  new  Corps  of  Engineers  Financial  Man¬ 
agement  System  (CEFMS).  The  development  of  a  DSS  that  is  able  to  analyze 
both  budget  allocation  and  corresponding  expenditures  is  a  future  research  item 
under  the  Decision  Support  System  work  unit  within  the  lOMT. 
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6  Results  and  Conclusions 


The  development  of  the  COMB_DSS  under  this  scope  of  work  was  really 
"proof-of-concept”  for  the  following  items: 

a.  Decision  suppcnt  development  tools  are  available. 

h.  The  technical  know-how  available  to  devdop  DSS*s  exists. 

c.  Corps  budget  processes  can  be  adapted  to  DSS  methodologies  and 
thinking. 

The  COMB^DSS  was  successfully  concq>tualizedy  designed,  devdoped 
throu^  iterative  prototyping  methods,  and  implemented.  The  success  of  this 
research  effort  can  be  attributed  to  the  Corps  personnd  who  were  involved  in 
the  project  and  are  subject  matter  experts  on  the  O&M  budget  process.  How¬ 
ever,  a  bettm-  understanding  of  the  COMBJDSS  capabilities  and  constraints 
may  have  lead  to  more  use  of  system  capacities  and  less  mimicking  of  the  way 
scenarios  are  developed  on  the  RAMIS  system. 

The  COMB_DSS  proved  sufficiently  fluid,  such  that  requirements  of  deci¬ 
sion  makers  wo-e  met  This  could  not  have  been  accomplished  without  the 
rapid  prototyping  that  followed  ongoing  changes  to  concept  and  design.  There 
were  many  capabilities  designed  into  the  COMB_DSS  (e.g.,  build  SQL)  that 
were  not  utili^  at  all  during  the  O&M  budget  submittal.  Although  the 
design  team  sought  to  change  the  way  the  decision  makers  approached  the 
problem,  the  desired  system  ouq>uts  were  the  same  as  those  desired  in  previous 
years.  However,  the  system  was  used  to  its  potential  through  the  devdopmoit 
of  over  250  budget  scenarios  (three  times  bi^er  than  in  previous  years)  indi¬ 
cating  that  user  demands  will  expand  to  system  capabilities. 
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Existing  ABS  System  and 
O&M  Budget  Process 


The  O&M  Budget  Process 

Overview 

The  Operatioiis  and  Maintmance  (O&M)  account  is  one  of  five  major 
programs  that  compose  the  Civil  Works  Bucket  for  the  Coips  of  Engineers.  It 
involves  a  $1.5  billion  annual  woik  effort  targeted  at  the  annual  idmtification 
and  selection  of  ^roximately  850  projects  from  a  total  inventory  of  1,400 
projects.  These  projects  are  re^nsible  for  the  maintenance  of  some  4,000 
individual  structures,  managed  by  Corps  District  and  Division  offices.  The 
budget  cycle  for  any  targeted  budget  year  (BY)  con^rises  2  years  beginning 
about  January  BY  >2  with  a  cost  estimate  of  individual  tasks,  drawn  up  at  the 
project  site  or  appropriate  organizational  dement  within  the  District  office. 
When  the  individual  tasks  are  grouped  into  work  functions,  there  are  20,000 
sqtarate  units  that  make  up  the  budget  requests  submitted  to  Congress  for 
aimual  fiscal  appropriations.  The  budgeting  process  allows  for  adjustments 
that  might  occur  due  to  shifting  administrative  priorities  or  unetqpected 
emergencies  requiring  immediate  unanticipated  reaction.  The  Corps  O&M 
program  execution  goals  are  to  physically  complete  the  funded  work  effort  in 
the  President’s  budget  together  with  any  Congressimial  add-on,  while  expend¬ 
ing  95  percent  of  annual  appropriation. 


Cycle  description 

The  O&M  budget  process  consists  of  managers  at  various  hierarchical 
levds  as  shown  in  Figure  Al.  Each  manager  is  re^nsible  for  formulating  a 
set  of  work  functions  for  consideration  at  the  next  highn  levd.  The  flowchart 
in  Figure  Al  dq>icts  an  upward  passing  of  the  budget  request  to  higher  mana¬ 
gerial  levels,  Cemgressiond  appropriation  at  the  summit,  and  a  reverse  down¬ 
ward  flow  to  represent  the  allocation  of  funding  resources.  The  chart  also 
illustrates  a  minimum  of  2  years  to  complete  this  cycle,  ftom  BY  -2  to  the 
actual  BY.  There  are  four  levels  of  review  within  the  Corps,  through  which 
priorities  are  set  for  work  functions. 
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Figure  A1.  Hierarchy  of  management 

The  senior  management  at  the  Headquarters  level  (HQUSACE)  recognizes 
that  a  nonuniform  woridng  structure  exists  at  the  field  level  where  decisions 
are  made  to  rank  and  fund  O&M  projects.  Although  guidance  in  the  form  of 
regulations  drives  the  O&M  budget  process,  the  q>ecific  manner  and  methods 
for  making  allocation  choices  are  not  prescriptive  of  internal  Corps  policy. 

Each  District  and  Division  appears  to  have  t^en  a  unique  stance  that  is 
centered  upon  a  combination  of  mission  orientation,  organizational  structure, 
national  socioeconomic  objectives,  r^onal  considerations,  and  other  factors. 

Various  factors  hinder  the  smooth  flow  of  the  O&M  budget  process.  For 
example,  emergency  dredging  during  flood  and  drought  events  rqrresents  an 
urgent  situation  that  requires  immediate  adjustment  There  is  no  separate  fund 
available  to  pay  for  these  onergency  operations,  and  the  money  most  be  chan¬ 
neled  from  previously  allocated  O&M  flscal  resources.  Another  problem 
results  from  differences  in  O&M  woricload  priorities  as  assessed  by  Held  opo*- 
ating  offices.  Evaluation  methods  currently  lack  consistency.  Furthermore, 
there  are  always  limited  funds,  thereby  forcing  a  cutoff  line  to  be  drawn  within 
the  list  of  maintenance  requirements. 

The  Corps  is  challenged  with  growing  maintenance  requirements  and  also 
escalating  operational  costs.  The  inventory  of  projects  is  inaeasing  annually 
due  to  the  maintenance  requirements  of  both  new  projects  and  oldCT  projects 
approaching  the  ends  of  their  design  lives.  New  operational  considerations 
associated  with  social  and  environmental  issues  that  were  not  present  when 
projects  first  became  operational  are  now  adding  to  the  costs  of  operation. 
There  is  a  need  for  uniform  efffciency  that  would  standardize  comparison 
among  work  in  different  categories.  Benefit-cost  assessments  would  improve 
decisions  within  a  specifle  mission  area,  such  as  flood  control  or  hydropower. 
However,  competing  projects  across  different  mission  reiqxrnsibflities  present 
an  added  dimension  to  the  evaluation  process.  Multiple  analytical  methods 
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must  be  oonskkfed  in  designing  a  weighing  system  that  brings  equilibrium  to 
multqde  goals. 


The  Automated  Budget  Syatem 

Historical  dsvsiopinsiit 

The  O&M  budget  was  originally  prqMred  in  aocmdance  with  the  principle 
of  zero-base  budgeting.  The  system  originally  designed  to  implement  this 
principle  greatly  improved  the  process  by  ordering  budget  requests  from  the 
field  ofiices.  Work  grouped  together  in  decision  packages  was  ranked  accord¬ 
ing  to  its  criticality  first  by  the  District  offices,  then  by  the  Division  offices, 
and  finally  by  CECW-OM.  Because  all  decision  packages  were  prioritized, 
CECW-OM  could  develop  an  optimum  program  mix  within  authorized  funding 
levels. 

This  original  system  was  not  sufficiently  flexible  to  handle  the  diverse 
programs  and  activities  that  make  up  the  O&M  qipropriations.  A  program  is 
an  area  of  activity  related  to  a  major  mission  of  tte  Corps  of  Engineers,  e.g., 
recreation,  power  generation,  navigation,  or  flood  control.  Frequently,  work 
functions  from  different  programs  were  placed  together  in  one  decision  pack¬ 
age.  When  decisions  made  about  a  specific  program  resulted  in  the  rq>rioritiz- 
atkm  of  work  in  that  program,  a  dtsaggn^tion  of  deciskm  packages  contain¬ 
ing  the  work  was  necessary.  Oonsequentty,  decisions  <»  Corps-wide  programs 
woe  difficult  to  inqilemait 

The  current  Automated  Budget  Syston  (ABS)  attempts  to  correct  those 
early  difficulties  and  to  facilitate  the  making  and  inq>lementation  of  budgetary 
decisions.  Work  functions  are  no  longer  grouped  together  into  decision  pack¬ 
ages  but  ate  treated  as  separate  decision  units.  Work  functions  are  cat^rized 
according  to  their  respective  programs  and  finance  and  accounting  feature  cost 
categories.  If  work  within  a  program  needs  to  be  reranked,  changes  to  the 
ABS  do  not  require  extensive  updates. 


ABS  characteri  itica 

Description  of  the  ABS.  The  ABS  is  an  upward  rqwrting  system  executed 
within  the  U.S.  Army  Coqts  of  Engineers.  It  serves  as  an  administrative  tool 
for  the  annual  preparation  and  submission  of  the  O&M  budget  to  the  Office  of 
Managonoit  and  Budget  (OMB).  ABS  was  designed  primarily  for  decision 
support  in  the  formulation  of  the  O&M  budget  submittal  and  continues  in  that 
role  at  the  present  time.  The  system  makes  use  of  a  fourth-generation  lan¬ 
guage,  RAI^S  n,  therefore  enabling  decision  makers  to  run  standard  rq»rts 
and  ad  hoc  quoies  that  drimnine  die  impacts  of  different  budgri  scenarios  on 
the  O&M  program. 
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Figure  A2.  Work  classification  hierar^ 


The  work  item  or  task  (Figure  A2)  rq>resents  the  lowest  levd  of  input 
information  in  the  system  structure.  This  is  the  most  disaggregate  levd  and 
pertains  to  a  discrete  activity  that  will  be  started  or  completed  within  a  budget 
year  (e.g.,  painting  a  lode  gate).  These  worie  items  can  be  aggregated  into 
work  /unctions  depicting  genod  areas  of  woric.  This  is  the  second  level  of 
hierarchy,  and  during  this  phase,  work  functions  are  categorized  in  accordance 
with  guiddines  set  forth  in  the  performance  levd  matrix  in  Engineer  Circular 
(EQ  11*2*108.^  Thus,  work  functions  are  prioritized  and  placed  within  their 
respective  funding  levds. 

A  function  is  made  op  of  a  collection  of  O&M  activities  bdonging  to 
a  program  and  rqjresenting  a  CCTtain  levd  of  effort  A  worit  function  is  identi- 
fled  by  a  spedfic  cost  code  and  funding  levd  as  ^>edfied  in  the  performance 
level  matrix.  Decision  unit  funding  analyses  can  \k  made  on  work  functions 
without  directly  affecting  otha*  work  functions.  Work  functions  are  assigned 
to  one  of  87  work  Junction  categories,  which  constitute  the  total  work  effort 
and  corre^nd  to  the  O&M  feature  cost  accounting  system.  These  categories 
are  not  rank-ordered  and  are,  therefore,  equal  coirpetitors  for  Congtessiond 
rppropriation.  Worit  functions  within  any  specified  category  are  subsequently 
graded  against  four  incremental  funding  levds  to  establish  their  importance 
rdative  to  one  anothCT.  The  levds  of  funding  range  from  a  minimum  capabil¬ 
ity  to  an  enhanced  level  of  work  effort  across  all  cateftories  of  work  effort 
Tlie  four  funding  levds  are  described  in  EC  11-2-157?  Levd  1  woric  func¬ 
tions  receive  the  highest  funding  priority,  whfle  Levd  4  woric  functions  receive 
the  lowest  funding  priority. 


^  HeadqnarleiB,  U.S.  Anny  Corps  of  EngineeiB.  ’Annual  Piogram  and  Budget  Request  fiar 
CSvil  Works  Activities,  Corps  of  Engineers  Fiscal  Year  1984,”  EC  11-2>106,  Washington,  D.C 
^  Headquarters,  U.S.  Army  Corps  of  Engineers.  ’Annual  Program  and  Budget  Request  Gor 
Civil  Works  Activities,  Corps  of  Engineers  Fiscal  Year  1992,’  EC  11-2-157,  Washington,  D.C 
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The  project  occupies  the  top  position  in  the  woric  classification  hierarchy. 
All  work  functions  must  belong  to  a  speciflc  authorized  O&M  project  A 
project  represents  completed  construction  of  one  or  more  major  civil  worits 
structures,  such  as  a  lock  or  a  dam  or  a  flood  (x>ntrol  reservoir,  that  is  being 
operated  and  maintained  through  O&M  budget  funds.  Each  project  is  q>eci- 
fied  by  a  name  (assigned  by  authorizing  act)  and  a  Civil  Works  Information 
System  (CWIS)  number. 


Management  levels.  There  are  four  levels  of  internal  management  and 
review  in  the  Corps  O&M  budget  process:  project  or  organizational  element. 
District,  Division,  and  HQUSACE  (Figure  A3).  Four  stages  can  be 


Figure  A3.  Levels  of  internal  management 

demarcated  within  each  level  of  review  in  the  budget  prqraration  process.  The 
first  stage  begins  with  the  creation  of  a  consolidated  database  consisting  of 
incoming  worit  function  information.  This  is  followed  by  review,  adjustments, 
and  finally  a  rank  order. 

Funding  levels  and  classification.  To  provide  a  uniform  approach  to 
program  developmoit  and  justifleation,  lour  incremental  funding  levels  are 


Appendix  A  ExMing  ABS  System  and  O&M  Budget  Process 


AS 


defined  and  iiiq>lanaited.  These  levds  are  ordered  with  the  smallest  level 
number,  1,  being  the  highest  priority  and  4  being  the  lowest  priority.  Thus, 
operation  and  maintenance  of  a  navigation  lock  would  be  included  in  Level  1 
while  less  critical  enhancements  or  improvements  would  be  placed  in  lower 
levels  (e.g.,  2,  3,  4).  Funding  levels  are  grouped  by  specific  categories,  as 
listed  in  Table  C2.1  of  EC  11-2-157.^  Table  C2.2  of  EC  11-2-157^  shows 
each  category  and  each  item  listed  by  level. 

A  work  function  can  be  a  single  task  or  group  of  equivalent  tasks  by 
definition.  Priorities  will  be  assigned  to  each  worit  function.  Ranking  of 
individual  work  functions  is  based  upon  field  discretion  within  each  level.  No 
ranking  across  levels  is  allowed.  Thus,  all  work  functions  for  Level  1  are 
ranked  only  for  Level  1,  Level  2  work  functions  are  ranked  only  for  Level  2, 
and  so  forth. 

The  criteria  for  placing  work  functions  in  each  of  the  four  funding  levels 
are  included  in  Table  C2.2.^  Following  is  a  brief  description  of  each  funding 
level: 


a.  Level  1,  the  minimum  funding  level,  is  limited  to  ensuring  public  health 
and  safety  and  a  reasonable  return  of  economic  and  other  benefits  from 
the  existing  investment  and  minor  or  ordinary  repairs  at  high-use 
projects  with  mainline  benefits  of  flood  control,  municipal  and  industrial 
water  supply,  commercial  navigation,  and  hydropower. 

h.  The  second  level  allows  initiation  of  funding  for  other  operations  con¬ 
sistent  with  reasonable  user  needs  as  well  as  increased  maintenance  to 
assure  adequacy  of  project  features  and  integrity  of  structures  through 
the  budget  year. 

c.  The  third  level  of  funding  is  considered  O&M  effort  consistent  with 
normal  and  customary  operation  of  project  features  and  at  a  cost 
approximating  that  of  the  previous  budget  year. 

d.  The  fourth  level  provides  for  danced  operations  and  maintenance 
above  the  current  level.  It  more  fully  operates  and  maintains  all  projects 
with  high  economic  benefits  to  a  standard  of  excellence  by  providing  for 
replacement  of  equipment  for  highly  efricient  operation  and  by  eliminat¬ 
ing  most  navigation  delays. 

Figure  A4  shows  the  general  progression  of  work  tasks  through  the  O&M 
budget  process  using  the  ABS. 

ABS  ranidng.  The  Corps-wide  database  is  the  final  aggregation  of  O&M 
budget  information,  and  is  created  from  integrating  and  consolidating  the  Divi 
sion  databases.  The  Division  databases  are  a  consolidation  of  the  District 


*  EC  11-2-157,  op.  cit. 
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Figure  A4.  Work  dass'ification  and  the  ABS 

databases,  which  are  edited  and  re-ranked  in  accordance  with  Division  priori¬ 
ties.  As  discussed  previously,  before  prioritizing,  ranking,  and  integrating 
work  functions  at  the  District  and  Division  levds  can  occur,  a  category  and 
funding  level  must  be  assigned. 

A  computer  program  written  in  C-language  was  created  by  HQUSACE  to 
facilitate  the  automated  database  integration  and  consolidation  process. 

Starting  with  Level  1,  the  first  work  function  for  each  Division  (or  District)  is 
prioritized  in  accordance  with  its  respective  category.  The  work  function  with 
the  highest  priority  relative  to  the  other  Division  competitors  is  then  placed 
into  the  consolidated  database.  The  next  work  function  is  then  pulled  from 
that  Division  to  compete  with  the  existing  work  functions  and  the  process  is 
rq)eated.  When  any  Division  extinguishes  10  percent  of  its  total  ^are  in  a 
given  level,  it  is  placed  on  hold  un^  all  of  the  other  Divisions  have  extin¬ 
guished  10  percent  This  process  continues  until  all  Level  1  work  functions 
have  been  placed  into  the  consolidated  database.  Levels  2,  3,  and  4  are  pro¬ 
cessed  in  the  same  manner  as  Level  1. 

This  method  is  fair  to  both  Divisions  and  Districts,  since  the  integrity  of  the 
priorities  set  by  either  entity  is  preserved.  The  consolidated  database  can  be 
pictured  as  an  empty  box,  being  filled  as  described.  Once  full,  it  is  flipped 
over,  and  at  the  top  are  the  Level  1  work  functions,  followed  by  the  Level  2 
work  functions,  and  so  forth.  Although  all  of  the  Division  work  functions  are 
integrated,  they  still  maintain  their  original  rank  ordo*.  This  procedure 
attempts  to  eliminate  any  bias  potential  of  this  type  of  data  int^ration.  Fig¬ 
ure  A5  shows  the  HQUSACE  ranking  procedure. 
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Figure  AS.  HQUSACE  ranking  procedure 


The  automat-:  ranking  process  is  a  good  way  to  obtain  an  initial  rank  of 
work  functions  within  a  funding  level.  Although  Divisions  and  HQUSACE 
have  the  option  to  use  the  automatic  ranking  procedure,  Districts  do  not 
Thus,  Districts  must  use  a  manual  ranking  procedure.  Division  offices  are 
encouraged  to  review  the  initial  rank  assignments  and  manually  adjust  them  to 
ensure  a  well-balanced  program  that  provides  a  justified  level  of  service  for  all 
projects.  HQUSACE  must  make  extensive  manual  adjustments  to  its  auto¬ 
matic  rank  assignments  both  individually  and  programmatically  to  produce  a 
balanced  nationwide  program. 

The  rank  for  any  work  function  is  a  Hve-digit  number  for  the  Divisions  and 
Districts,  and  a  seven-digit  number  for  HQUSACE.  The  first  and  leftmost 
digit  for  each  rank  number  always  corre^nds  to  the  funding  level.  The 
remainder  of  digits  are  sequenced  by  order  of  importance  in  increasing  order 
for  each  funding  level.  Typically,  each  number  in  the  sequence  will  differ 
from  the  last  by  two  or  three.  This  allows  room  for  the  integration  of  addi¬ 
tional  and/or  changed  work  functions  at  a  later  point  in  time.  HQUSACE  uses 
a  seven-digit  number  because  (a)  they  must  rank  all  of  the  District  and  Divi¬ 
sion  work  functions  together,  and  (b)  they  typically  keep  particular  work  func¬ 
tions  logically  grouped  using  the  fourth  and  flfth  digit  in  the  rank  number. 


The  ABS/O&M  interface 

The  interface  between  the  ABS  system  and  t>*e  O&M  budget  begins  with  a 
Corps-wide  meeting  involving  the  Districts,  Di\  .:ions,  and  HQUSACE. 
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During  this  meeting,  which  is  generally  held  by  March  BY  -2,  HQUSACE 
gives  qjeciflc  budget  guidance  and  each  Division  receives  a  target  budget  to 
guide  their  internal  rankings  and  decisions.  During  this  time,  ABS  training 
may  be  held  for  the  Districts.  If  there  are  any  changes  to  the  ABS  system, 
they  are  announced,  explained,  and  implemented.  The  events  that  precede  and 
follow  the  meeting  are  discussed  in  the  following  paragraphs  and  are 
represented  in  Figure  A6. 
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Figure  A6.  O&M  budget  cycle  and  ABS  activities 


As  early  as  January,  each  District  has  on-site  project  managers  compile  a 
list  of  work  items  to  accomplish  in  the  budget  year  at  the  project  level.  The 
District  then  reviews  project  level  information,  makes  a  few  initial  adjustments, 
and  adds  new  project  records.  After  updating  in  late  March  to  early  ^ril,  the 
District  ranks  work  functions  by  order  of  importance  and  assigns  them  to  a 
funding  level  by  category. 

The  District  suimnarizes  work  item  information  for  each  work  function  to 
include  such  items  as  contract  costs,  supervision  and  administration  costs,  and 
estimated  dredging.  The  work  is  entered  into  local  microcomputers  and 
uploaded  to  the  Washington  Computer  Center  (WCC)  by  mid-May. 
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From  mid-May  to  mid-June,  Division  databases  are  downloaded  from  WCX!^ 
to  local  microcomputers.  District  budget  submittals  are  reviewed,  adjusted, 
and  uploaded  back  to  the  WOC  mainframe.  District  offlces  may  then  contact 
the  Division  office  to  dispute  any  adjustments  they  feel  are  questionable.  Any 
necessary  adjustments  are  made  to  the  Division  database  prior  to  Corps-wide 
integration. 

Sometime  between  June  ISth  and  July  15th,  HQUSACE  consolidates  each 
Division  database  into  a  single  agency-wide  database  using  the  ranking  process 
described  previously.  To  this  end,  the  District  and  Division  offices  may 
review  any  adjustments  made  by  HQUSACE.  After  negotiating  sensitive 
adjustments,  the  consolidated  database  is  revised.  Toward  the  end  of  July, 
HQUSACE  submits  the  budget  proposal  to  the  Assistant  Secretary  of  the  Army 
(ASA)  for  approval.  Changes  are  then  made  to  the  database  as  dictated  by  the 
ASA. 

By  September  1st,  the  Civil  Works  Operation  &  Maintenance  Budget  is 
presented  through  the  ASA,  Civil  Works  (CW),  to  the  0MB,  and  is  then 
returned  to  HQUSACE  by  late  November.  In  December,  HQUSACE  requests 
Divisions  to  prepare  "Justiflcation  of  Estimate”  sheets  for  presentation  to  Con¬ 
gress  after  OMB  has  given  the  Corps  its  Hnal  program. 

Starting  late  January  to  early  February,  rq)resentatives  from  each  Division 
are  sent  to  justify  their  budget  before  Congress.  These  representatives  use 
information  generated  by  the  ABS  rq>orts  to  answer  questions  brought  before 
them  during  the  hearings  on  Capitol  Hill.  Cdngress  will  deliberate  on  the 
testimony  of  these  representatives  and  pass  an  q>propriations  bUl  in  October  of 
the  BY.  The  funds  are  then  distributed  to  the  District  for  obligation  and 
expenditure. 


Example 

This  example  illustrates  the  process  that  work  tasks  undergo  before  funding. 
A  work  task  (e.g.,  painting  lock  gates  at  Facility  A)  is  tracked  from  the  initial 
request  for  funding  to  ultimate  receipt  of  the  funds,  as  a  work  function.  Cur¬ 
rently  individual  tasks  are  not  tracked  from  the  initial  request  to  the  receipt  of 
funds.  However,  the  District  Operations  &  Maintenance  Budget  System  is 
working  toward  getting  data  distributed  to  this  level. 

The  request  for  funding  begins  at  the  project  level  with  a  work  task,  which 
is  the  smallest  unit  of  work  at  a  Corps  facility.  For  funding  purposes,  similar 
work  tasks  are  normally  pooled  together  into  a  work  function  by  the  Project  or 
Area  Managers.  Not  all  worir  tasks  are  necessarfly  aggregated  into  a  woiic 
function  because  some  tasks  are  unique  and  can  stand  alone,  such  as  backup 
generator  maintenance  at  a  Corps  dam.  In  this  example,  painting  the  lock 
gates  at  Facflity  A  and  painting  the  lock  gates  at  other  area  locks  might  be 
combined  into  a  work  function.  This  work  function  is  placed  into  a  proposed 
O&M  budget  request  that  is  sent  to  the  District  There,  these  work  functions 
are  assign^  funding  levels  according  to  their  importance  to  the  project’s 
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mission  and  are  placed  into  one  of  87  work  function  categories  (such  as  Lock 
Operations).  These  assigned  funding  levels  range  from  1  to  4,  with  Level  1 
representing  those  work  functions  critical  to  the  mission  of  the  project,  and 
level  4  representing  work  functions  that  provide  enhancement  of  the  project 
but  are  not  critical  to  its  mission.  Thus  Level  1  items  will  receive  funding 
before  a  Level  2  item.  Maintenance  of  a  backup  generator  at  a  Corps  dam 
may  typically  receive  a  Level  1  assignment,  the  painting  of  a  lock  gate  may 
receive  a  Level  2  assignment,  and  painting  picnic  tables  at  a  Corps  recreation 
area  may  be  assigned  to  the  fourth  funding  level.  These  assignments  are  con¬ 
ducted  at  the  District  level  and  are  based  on  the  Performance  Level  Matrix 
guidelines  provided  in  EC  11-2-108.^ 

After  each  work  function  is  assigned  to  a  funding  level,  it  is  evaluated  and 
ranked  again  within  each  funding  level.  For  example,  painting  the  lock  gates 
at  Facility  A  may  have  received  a  Level  2  assignment,  as  did  the  painting  of 
lock  gates  at  all  other  locks  in  that  District.  To  compare  these  Level  2  work 
functions,  they  will  be  given  rankings  such  as  20000,  20010,  20020.  There¬ 
fore,  a  work  function  given  the  ranking  of  20000  will  have  greater  funding 
priority  over  a  work  function  given  a  20020  ranking.  Although  each  O&M 
manager  ranks  all  work  functions  within  a  funding  level,  it  does  not  mean  that 
each  work  function  is  from  the  same  category.  For  example,  a  manager  may 
have  to  directly  decide  the  rank  of  a  lock  gate  getting  painted  against  a  rest 
area  being  maintained. 

The  challenge  for  the  O&M  manager  is  to  rank-order  all  Level  2  work 
functions  within  a  given  category.  Similarly,  he  or  she  must  also  rank  order 
all  work  functions  (or  separate  work  tasks)  for  each  funding  level  within  every 
category.  This  means  that  the  manager  who  has  multiple  functions  that  fUl  all 
4  levels  of  all  87  categories  must  satisfy  4  x  87,  or  348,  decision  points  to 
complete  rank-ordering.  Of  course,  it  is  likely  that  the  District  O&M  manager 
has  work  functions  for  only  some  of  the  87  categories,  and  the  choices  and 
rank  ordering  challenge  are  reduced,  but  still  complicated. 

In  this  example,  suppose  Facility  A  has  had  the  painting  of  its  lock  gates 
postponed  for  several  funding  cycles.  Another  facility  (Facility  B)  may  have 
had  its  lock  gates  painted  recently,  but  for  the  purpose  of  routine  maintenance 
funds  are  requested  again  for  this  activity.  Facility  A  may  exhibit  greater 
need;  therefore  painting  Facility  A’s  lock  gates  might  receive  a  ranking  of 
20000,  while  painting  the  lock  gates  at  Facility  B  might  receive  a  ranking  of 
only  21000.  Once  these  work  functions  have  been  rank-ordered  in  their 
respective  funding  levels  by  the  District,  the  information  is  then  uploaded 
through  the  ABS  to  the  Division  for  consolidation  with  the  other  District 
databases. 

The  process  of  database  consolidation,  review,  adjustment,  and  prioritization 
occurs  at  the  District,  Division,  and  HQUSACE  level.  The  amount  of  reprior¬ 
itization  decreases  as  the  O&M  budget  request  moves  up  the  management 
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hierarchy  through  the  ABS  to  HQUSACE.  At  each  level,  a  work  function 
from  one  category  competes  against  work  functions  from  all  other  Districts  in 
a  Division,  and  then  against  all  Divisions  in  the  Corps.  Once  the  budget 
request  arrives  at  HQUSACE,  the  process  of  aggregating  all  previously  input 
work  functions  begins.  Not  all  work  functions  entered  will  receive  funding. 

An  issue  of  major  importance  to  local  managers  is  the  location  of  the  funding 
cutoff  line  established  by  HQUSACE.  Due  to  budgetary  constraints  and 
increasing  maintenance  needs,  the  cutoff  line  for  funding  has  shifted  to  a  point 
somewhere  within  Level  2. 

Remembering  the  notion  of  a  cutoff  line,  and  referring  to  Figure  A7,  all 
Level  1  work  functions  in  the  87  categories  will  be  funded,  as  well  as  those  at 
Levels  2a  and  2b.  This  suggests  that  the  cutoff  line  is  going  to  be  drawn 
somewhere  in  Level  2c.  The  work  functions  in  Level  2c  above  the  cutoff  line 
will  be  funded,  but  the  Level  2c  work  functions  below  the  cutoff  line  will  not 
receive  funding.  The  work  functions  at  Levels  3  and  4  will  also  be  excluded 
from  funding  unless  exceptional  circumstances  and/or  appropriate  justification 
are  submitted  by  the  requesting  District/Division  and  approved  at  HQUSACE. 
Therefore,  the  painting  of  Facility  A’s  lock  gates  will  receive  funding  due  to 
its  rank  of  20000.  However,  what  happens  to  Facility  B’s  request  for  painting 
of  its  lock  gates?  Since  it  has  a  ranking  of  20260  and  the  cutoff  line  is  drawn 
within  that  level,  it  may  or  may  not  receive  funding.  The  category  to  which 
this  2c  work  function  belongs  may  affect  its  placement  above  or  below  the 
cutoff  line.  Although  Corps  regulations  emphasize  that  the  funding  postures  of 
the  categories  are  equal,  the  President’s  budget  guidance  does  create  an 
anangement  of  the  categories.  Of  the  87  competing  categories,  some  may 
receive  more  emphasis  due  to  the  policies  of  the  current  Administration.  In 
other  words,  in  any  fiscal  year,  one  category  may  become  more  important  than 
another.  A  category  becomes  essential  in  the  ranking  process  only  when  two 
work  functions  &om  different  Districts/Divisions  have  been  ranked  in  the  same 
area  within  the  funding  level. 

Each  Division  receives  funding  for  those  projects  above  the  cutoff  line. 

The  Divisions  allocate  this  money  to  the  Districts  according  to  the  costs  for 
performing  Level  1  and  2a,  2b,  and  some  2c  woric  functions.  The  Divisions 
and  Districts  retain  some  necessary  flexibility  in  allocating  the  money  they 
receive.  This  flexibility  is  important  because  money  may  have  to  be  diverted 
from  work  functions  that  received  funding  in  order  to  address  unforeseen  cir¬ 
cumstances.  Keep  in  mind  that  it  will  have  been  18-24  months  since  the  origi¬ 
nal  budget  request  was  submitted,  and  time  may  have  altered  intended  events. 
An  adjustment  of  funds  may  occur  when  conditions  at  the  facility  change, 
emergency  situations  arise,  or  "slippage”  in  work  occurs,  wherein  not  all  the 
allotted  money  is  spent  as  initially  anticipated.  This  means  that  some  Level  2c 
and  2b  work  functions  may  not  receive  money  even  though  they  were 
approved  for  funding  at  the  HQUSACE  level. 
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Rgure  A7.  Hypothetical  example  of  O&M  funding  process 

Existing  System  Design 

This  section  provides  an  overview  of  the  hardware  and  software  require¬ 
ments  of  both  the  microcomputer  and  mainframe  versions  of  the  ABS.  A 
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discussion  of  the  data  structures,  the  functional  relationships  among  tables,  and 
available  reports  are  provided  for  each  system. 

The  micro-ABS  program  was  generated  using  the  Clipper  S.O  compiler. 
Qipper  operates  on  the  dBase  III  file  format  and  offers  a  command  set  which 
fully  encompasses  that  of  dBase  III.  Gipper’s  added  capabilities  include  many 
functions  and  libraries  which  allow  creation  of  menus,  pick-lists,  data  entry, 
and  other  types  of  front-end  interfaces.  Because  dBase  III  formats  exist  in 
micro-AB^  "index  Hies"  are  available  which  allow  the  ordering  of  data  flies 
by  various  criteria  without  the  need  to  physically  sort  the  file  on  disk. 

On  the  WCC  mainframe,  the  RAMIS  II  database  management  system  han¬ 
dles  data  relationships  quite  like  the  personal  computer  version.  Many  reports 
are  available  on  the  mainframe  as  well  as  the  microcomputers  for  managers  of 
all  levels.  The  relational  data  structures  are  ideal  for  data  modification.  An 
ASCII  flat-file  export  capability  facilitates  file  transfers  from  District  and 
Division  to  HQUSACE. 


Overview  of  system  architecture 


The  ABS  is  characterized  by  an  intricate  network  of  computer  systems  at 
all  user  levels  of  review.  The  basic  operations  of  the  O&M  budgeting  process 
can  be  executed  through  mainframe/minicomputers,  and  microcomputers  using 
ABS  (see  Figure  A8).  This  network  is  available  at  the  District,  Division  and 


Figure  A8.  Computers  used  fw  the  O&M  process 
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HQUSACE  level.  The  District  update  begins  with  the  creation  of  a  District 
database  on  the  V/CC  mainframe  computer.  It  is  then  downloaded  as  work 
function  data  to  District  microcomputers  for  data  update.  After  completion  of 
the  update,  the  District  data  are  exported  to  a  single  flle,  and  uploaded  to  the 
WCC  mainframe  computer. 

District  databases  are  consolidated  into  the  Division  database  on  the  WCC 
mainframe.  The  Division  can  then  download  and  review  its  own  database  for 
adjustments  and  prioritization.  Data  adjustments  and  ranking  are  facilitated 
through  micro-ABS,  which  also  provides  a  way  to  download  and  upload  the 
data.  This  process  can  occur  many  times  prior  to  the  cycle  date,  at  which  time 
the  projects  are  presented  to  Congress  and  the  funds  are  appropriated. 

Telecommunications  between  the  microcomputers  and  the  WCC  mainframe 
are  accomplished  using  the  Kermit  protocol,  lliis  protocol  is  simply  a 
"modem  language"  common  to  the  microcomputer  and  WCC  communication 
software. 


important  information  transfers 

District  information  transfers.  Beginning  with  the  1989  budget  submittal. 
District  offices  use  microcomputer  systems  to  access,  update  and  submit  bud¬ 
get  data.  This  is  a  five-stqi  process  designed  to  be  simple  yet  able  to  accom¬ 
modate  the  full  range  of  computing  and  communications  hardware  used  in 
District  offices. 

First,  the  District  database  is  created,  using  a  menu  of  options  to  create  a 
single  file  on  the  WCC  mainframe  computer,  otherwise  known  as  the  Navy 
Regional  Data  Automation  Center  (NA^AQ.  Figure  A9  shows  bow  District 
data  are  processed  and  transferred  to  and  from  the  WCC/NARDAC 

Second,  the  budget  data  are  imported  from  a  single  file  into  the  ABS. 

Third,  it  is  then  modified  on  that  microcomputer,  or  other  microcomputers  in 
the  District.  When  modifications  are  complete,  the  process  turns  around. 

Fourth,  the  data  are  exported  from  the  micro-ABS  to  a  single  file.  Micro- 
ABS  automatically  adds  job  control  language  to  the  file  upon  export  Fifth, 
using  communication  software  and  the  Kennit  protocol,  the  budget  upload  file 
is  transferred  back  to  the  WCC  mainframe. 

After  a  District  office  has  completed  updating  and  uploading  its  budget 
submission  database,  they  may  continue  to  make  changes  on  their  microcom¬ 
puters.  Then  they  upload  only  that  part  of  the  database  that  contains  the 
changed  work  functions.  The  uploaded  information  is  then  incorporated  into 
the  mainframe  District  database  by  rurming  several  available  edit  and  load 
programs.  These  edit  and  load  programs  wOl  produce  a  set  of  error  rqrorts  for 
review  and  adjustment  by  District  personnel.  Also,  each  District/Division  can 
run  reports  on  the  WCC  system  to  verify  the  accuracy  of  the  established  or 
updat^  database. 
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After  each  District  database  is  established  and  verified,  the  Division  office 
is  notified  that  the  District’s  submission  is  ready  for  review.  The  Division 
office  uses  the  standard  rqports  available  from  the  WCX^  District  Main  Moiu 
and  RAMIS  II  ad  hoc  queries  for  reviewing  the  individual  District  databases 
prior  to  establishing  the  Division  database.  Correq;)ondence  betweoi  the  Divi> 
sion  and  Districts  is  generated  through  the  Programs  Managonent  Offlce  or 
other  established  directorates  to  resolve  differences  noted  in  each  District  data¬ 
base.  Division  comments  and  Districts  rebuttals  are  established  to  resolve 
conflicts  in  the  District’s  budget  submission.  Any  District/Division  interaction 
not  resolved  using  the  rebuttal  method  of  checks  and  balances  is  continued 
after  the  Division  database  is  established. 


Division  information  transfers.  Beginning  with  the  fiscal  year  1990  bud¬ 
get  submittal.  Divisions  review  and  adjust  their  budgets  in  mu(±  the  same  way 
as  the  Districts.  After  the  District  databases  have  been  uploaded  to  the  WCC 
and  District/Division  personnel  have  run  reports  to  assure  that  the  District 
databases  are  correct,  CECW-OM  wfll  consolidate  the  District  databases  into 
the  Division  database.  The  Division  may  then  log  on  to  the  WCX^  and  down¬ 
load  the  consolidated  database  for  review  and  adjustment 

Once  the  Division  database  has  been  established,  it  is  prudent  for  the  Divi¬ 
sion  to  run  whatever  main&ame  reports  necessary  to  ensure  that  a  usable 
database  has  been  created.  After  the  Division  database  has  been  created  and 
prior  to  downloading,  the  Division  may  elect  to  have  HQUSACE  run  an  auto¬ 
matic  ranking  program  to  assign  initial  rankings  to  work  functions  on  the 
Division  database  on  the  mainframe  computer.  Then  the  database,  conqrlete 
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with  proposed  adjustments.  Is  returned  (uploaded)  to  WCC  Figure  AlO 
depicts  data  transfer  between  Divisk>ns  and  WCC. 


Figure  A10.  Data  transfer,  Division/WCC 

Like  a  District,  a  Division  may  make  more  than  one  upload.  The  Division 
may,  at  its  discretion,  use  this  feature  to  allow  the  Districts  to  review  Division 
revisions  to  their  budgets  before  the  CECW-OM  database  is  created.  When 
the  Division  uploads  to  the  WCC,  adjustments  will  be  written  to  a  sq>arate 
file,  as  well  as  to  the  Division  database.  The  Division  may  then  dect  to  have 
the  Districis  run  a  correction  rq>ort  against  the  budget  year  Division  database 
and  make  comments.  The  Division  always  has  the  option  to  make  changes  on 
its  microcomputer  database  and  re-upload 

HQUSACE  information  transfers.  HQUSACE  adjustmrat  and  ranking 
procedures  on  the  computer  are  essentially  the  same  as  the  Division  office’s 
procedures.  HQUSACE  creates  a  consolidated  Corps-wide  database  by  com¬ 
bining  data  firom  all  Division  databases.  When  adjustments  are  made,  they  are 
put  into  a  file  that  can  be  accessed  by  both  Division  and  District  offices. 
Adjustments  are  not  ^plied  to  the  HQUSACE  database  until  Divisions  have 
had  a  chance  to  rebut  theiiL  After  the  ranking  process  has  beat  completed  at 
HQUSACE,  the  Corps-wide  database  is  made  available  to  all  District  and 
Division  offices  so  diey  may  run  rqrorts  to  detomine  die  status  of  their  bud¬ 
get  Refer  *o  Figure  A6  for  a  time  cycle  depiction  of  the  O&M  budget  process 
activities  along  with  the  most  important  ABS  cycle  activities. 


System  environment 

Mlcrocompnter  requirements.  Micro-ABS  requires  a  microconqiuter  with 
a  modem,  capable  of  at  least  1200  baud  communications.  Along  with  the  five 
installation  disks  for  micro-ABS,  a  communications  program  called  Procomm 
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is  included  Other  communication  programs  may  be  used  instead  of  Procomm. 
However,  the  Kermit  protocol  must  be  used  to  accomplish  correct  communica¬ 
tions  with  the  mainframe.  It  is  recommended  that  the  microcomputer  have  at 
least  640K  memory.  Printers  are  optional  but  recommended 

In  the  past  Harris  minicomputers  played  a  large  role  in  the  data  transfer 
mechanism.  The  Harris  minicomputers  were  typically  distributed  to  each 
District  Those  Districts  without  a  Harris  could  utilize  one  at  an  adjacent 
District  Since  the  Harris  is  no  longer  required  in  the  O&M  Budget  Cycle 
process,  they  are  not  discussed  in  detail.  Districts  still  have  the  ability  to 
download  files  to  the  Harris.  This  allows  them  to  utilize  the  high-^eed 
printers  available.  This  is  useful  for  those  reports  that  tend  to  be  very  large. 
Figure  All  shows  the  general  hierarchy  of  computers  and  their  uses,  including 
the  Harris  computers. 


Rgure  A1 1 .  ABS  computer  hierarchy 


V/CC  mainframe  requirements.  The  WCC  mainframe  is  from  Hitachi 
Data  Systems  and  has  an  XL/80  production  processor.  This  mainframe  is 
designed  to  be  an  IBM  clone.  Thus,  IBM  mainframe  software  and  hardware 
can  be  utilized  The  communication  parameters  are  as  follows: 


Baud  rate 
Data  bits 
Stop  bits 
Duplex 
Parity 


1200,  2400,  9600 
8 
1 

Half 

None 
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The  RAMIS  II  database  management  system  software  is  a  product  of 
Online  Software,  Inc.  RAMIS  II  is  a  complete  fourth-generation  database 
management  system  with  its  own  native  language.  The  CX)BOL  programming 
language  is  us^  in  update  programs,  where  edit  checks  are  required  before 
data  are  entered  into  the  database  file.  All  of  the  standard  reports  and  ad  hoc 
queries  are  written  in  the  RAMIS  II  ad  hoc  query  language  and  the  RAMIS  II 
SBX  procedural  language. 


System  structure 

Micro-ABS  relational  structure.  The  micro-ABS  has  9  major  database 
files  and  22  different  index  flies.  A  database  file  may  have  up  to  15  active 
indices  (Clipper  Constraint).  However,  none  of  the  ABS  databases  contain 
more  than  10  indices.  Following  is  a  brief  description  of  these  data  files  and 
the  corresponding  index  files.  As  mentioned  previously,  these  index  files 
allow  the  databases  to  appear  sorted  according  to  the  index  file’s  "index  key." 
The  index  keys  for  each  index  file  are  also  listed  to  show  the  different  ways 
that  data  can  be  sorted  and  printed  by  the  micro-ABS  program.  Table  A1 
shows  the  actual  data  flies  and  index  file(s)  for  each.  Appendix  B  lists  the 
flelds  for  each  data  file. 

Note  that  the  index  files  denoted  with  an  *  are  temporary.  Temporary 
indices  are  for  reporting  or  using  other  features  that  do  not  require  the  index 
for  proper  micro-ABS  execution.  The  "STRQ"  indicates  that  a  numeric  field  is 
converted  to  a  character  field.  This  allows  micro-ABS  to  have  both  a  charac¬ 
ter  field  and  a  numeric  field  together  in  a  single  index  key. 

Key  fields  such  as  APPROP  PRJNAME  are  compound  keys  (e.g.,  the 
database  has  primary  and  secondary  sort  Adds).  In  this  example,  APPROP  is 
the  primary  sort  field.  This  makes  all  data  in  a  database  appear  to  be  in  order 
by  the  APPROP  field.  When  there  are  multiple  records  with  the  same 
APPROP  field  entry,  a  check  is  done  on  the  secondary  sort  key,  in  this  case 
PRJNAME.  There  may  be  many  secondary  keys,  as  shown  by  several  of  the 
indices  listed  in  Table  Al.  There  is  no  set  relationship  between  the  database 
files.  Any  database  file  containing  the  same  field  as  another  can  be  inter¬ 
related  by  virtue  of  an  index  file  with  the  common  fleld  setup  as  the  primary 
key. 

WCC  RAMIS  II  ad  hoc  queries.  The  query  language  that  comes  with  the 
RAMIS  n  Database  Management  System  is  a  powerful  fourth-generation  lan¬ 
guage  that  allows  the  creation  of  reports  with  user-friendly  commands.  A 
minimum  amount  of  training  is  required  to  generate  most  simple  rqx>rts.  A 
training  course  is  periodically  offered  by  On-line  Software  for  those  interested 
in  learning  more  data-intensive  report  gmmtion. 
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Table  A1 

Micro-ABS  Data  Flies  and  Indices 

DaMtaae 

■IQVX  rHOT 

index  Key 

CATFEAT.DBF 

CATFEAT.NTX 

FEATCOOE  CATCOOE 

•CATEMP.NTX 

CATCOOE 

CATEXC.OBF 

CATEXC.NTX 

CATCOOE 

CE_COST.OBF 

CEJNOEX.NTX 

STR(YEAR,2)  ^  STR(CW1S,5)  4- 

STR(FUNaD.4)  ♦  CE_FIELD  +BREAK_FLD 

NAV_DET.DBF 

NAV_DET.MTX 

STR(CWIS.9  *  STR(REACH,4) 

NAV_PWW.OBF 

NAV_PORT.NTX 

STR(CWIS.q  *  STR(REACHI0.4)  -4 

STR(WWCODE,4)  -4  STR(PORTCODE1 ,5) 

NAV_PWW.NTX 

STR(CVMS.S)  4-  STR(REACHID,4)  -4 

STR(WWCOOE.4) 

ORGFILE.DBF 

ORGINDEX.im 

ORGCOOE 

PRJFILE.OBF 

PRJINOEX.NTX 

STR(CV\nS,5) 

•PRJPCCW.NTX 

PRJCLASS  4-  STR(CWIS,5) 

•PRJPCPN.MTX 

PRJCLASS  f  PRJNAME 

STATEFILOBF 

STINDEX-NTX 

STATE 

WRKRLE.DBF 

•WORGNFOR.NTX 

ORGCOOE  4-  FUNOLEVEL  4-  STR03I8TRANK.4) 

•VVRCWNFDR.NTX 

STR(CWIS,5)  4-  STR(NUMFUN0,1)  4- 

STR(0iSTRANK,4) 

WRKAfV.NTX 

APPROP  +  STR(YEAR.2)  4.  SnrR(CWIS.5) 

•WRKCAT.MTX 

CATCOOE  4.  APPROP 

•WRKCWFC.NTX 

STR(CWIS.5)  -4  FEATCOOE 

WRKKEY.NTX 

STR(YEAa2)  4-  STR(CWIS.5)  4-  STR(FUNaO,4) 

•WRKNFDR.NTX 

STR(NUMFUN0,1)  -4  STR(0ISTRANK.4) 

•WRKREACH.NTX 

STR(CWIS,S)  4-  STR(REACHIO,4)  4-  STR(YEAR.2) 

•WRKTABI.NTX 

APPROP  4.  PRJNAME 

*WRKrAB2.NTX 

SrrR(YEAR.2)  4.  STR(NUMFUN0.1)  4- 

Srm(D(STRANK,4) 

The  RAMIS  II  query  language  consists  of  a  numbCT  of  simple  commands 
that  may  be  combined  togetho’  in  diffo'ent  configurations.  Thoe  are  seven 
basic  commands  that  the  query  language  recognizes: 
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a.  Define  Conunand  (DEFINE).  This  command  creates  new  data  elements 
from  values  of  existing  elements.  This  command  is  useful  when  func¬ 
tions  such  as  totalling,  subtotaling,  and  other  calculations  are  required. 

b.  Report  Conunand  (TABLE).  This  conunand  signifies  to  RAMIS  11  to 
prepare  a  report  This  command  is  used  by  itself,  and  is  not  used  along 
with  other  commands. 

c.  File  Identifier  Conunand  (FILE).  This  conunand  identifies  the  file  from 
which  RAMIS  II  system  will  generate  a  rqxirt  For  1991,  all  budgetary 
reports  use  the  file  name  OMB91  as  the  file  identifier.  The  actual 
conunand  used  to  identify  the  Hlename  in  RAMIS  n  would  be  FILE 
OMB91. 

d.  Display  Verb  Commands  (PRINT  or  SUM).  These  conunands  indicate 
which  data  element  values  to  di^lay  on  the  repoTL  The  field  names 
entered  are  sq>arated  by  the  words  "AND"  or  "OR"  (e.g.,  PRINT 
TOTCOST  AND  DESCRIPT  OVER  PROJNAM). 

e.  Sequencer  Command  (BY).  This  command  indicates  the  order  in  which 
data  element  values  will  be  di^layed  on  the  rqrort  It  also  sets  a  break¬ 
point  for  subtotal  calculations.  The  values  of  each  data  element  q)eci- 
fied  after  the  BY  command  determine  the  order  in  which  the  data  ele¬ 
ments  on  the  PRINT  and  SUM  conunand  wQl  be  displayed.  If  two  BY 
statements  are  used,  the  values  of  the  data  element  in  the  first  BY  state¬ 
ment  dictate  the  primary  sort  and  the  values  of  the  data  element  in  the 
second  BY  statement  determine  the  secondary  sort 

f.  Selector  Command  (IF).  In  most  of  the  queries  written,  it  is  desirable  to 
display  a  small  number  of  records  from  the  database  that  meet  cntain 
criteria.  The  IF  statement  allows  you  to  select  records  based  on  the 
critma  specified. 

g.  Query  Delimiter  Conunand  (END).  Titis  command  signals  the 
RAMIS  n  system  that  the  query  definition  is  finished.  The  system  wfll 
then  begin  to  process  the  query  request  and  produce  the  report 


Tentative  Changes  to  ABS 

This  section  currently  describes  two  toitative  changes  to  the  ABS.  First  is 
the  adoption  of  the  conation  index  (Q).  Second  is  the  ongoing  port  or  trans¬ 
fer  of  the  ABS  from  RAMIS  II  on  an  IBM  done  mainframe  to  ORACLE  on  a 
CDC  computer.  Each  of  these  changes  is  further  described  in  the  sections  that 
follow. 
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Condition  index 


The  Cl’s  are  intended  to  provide  uniformity  and  objectivity  in  making 
structural  observations  of  similar  facilities.  The  designed  set  of  engineering 
observations  is  used  in  mathematical  formulas  to  create  a  final  Cl.  Thus, 
objective  comparisons  can  be  made  between  a  navigation  structure  and  a 
recreation  structure.  Cl  values  range  from  0  to  100.  The  range  is  composed 
of  three  zones,  as  follows: 

a.  Zone  1  =  100  -  70  and  indicates  excellent  to  very  good  condition 

b.  Zone  2  =  69  -  40  and  indicates  good  to  fair  condition 

c.  Zone  3  =  39  -  0  and  indicates  poor  to  failed  condition 

The  ABS  contains  a  defunct  field  called  "output  measure. "  For  the 
OMB94  submittal,  this  field  will  contain  the  Cl.  Although  there  are  issues  to 
resolve,  HQUSACE  intends  to  consider  Cl’s  in  the  decision-making  process. 
Current  HQUSACE  concerns  about  CIs  include  (a)  the  fact  that  existing  guid¬ 
ance  is  vague;  and  (b)  the  fact  that  Cl’s  are  qiplicable  to  work  items,  not 
v/otk  functions.  Since  work  itans  receive  Cl  ratings  and  work  functions  are 
processed  by  the  ABS,  it  is  necessary  to  derive  a  composite  condition  index 
(CCI)  or  to  separate  the  work  function  into  its  individual  items  of  work  each 
having  its  own  Cl.  The  CCI  will  be  a  function  of  all  corresponding  work 
item  Cl’s.  It  is  unclear  how  the  con^site  CCI  will  be  derived  from  its  child 
Cl’s.  Current  possibilities  include  taking  the  high  or  low  Cl,  taking  an  arith¬ 
metic  mean  of  all  Cl’s,  or  taking  a  weighted  mean  of  each  Cl.  The  weighted 
mean  CCI  is  probably  the  most  accurate  and  viable,  provided  that  an  engi¬ 
neering  analysis  is  performed  to  assign  weights  to  each  Cl  category.  An 
interim  solution  may  be  found  in  concurrent  research,  which  is  seeking  to 
develop  a  "summary"  Cl  based  on  professional  expert  judgement. 


Port  to  oracle 

The  mainframe  ABS  currently  resides  on  an  IBM  computer  at  the  WCC. 
The  database  queries  are  done  using  RAMIS  n.  Update  routines  are  written 
in  COBOL  with  imbedded  calls  to  the  RAMIS  II  database  management  sys¬ 
tem.  Reports  and  ad  hoc  queries  are  written  in  the  RAMIS  II  native 
language. 

The  U.S.  Army  Engineer  Waterways  Experiment  Station  has  ported  the 
RAMIS  n  queries  from  the  IBM  clone  to  ORACLE  on  a  CDC  computer. 

This  port  takes  advantage  of  the  CEAP-backbone  capabilities  (e.g.,  high-speed 
access,  etc.)  and  complies  with  the  1995  Corps  Corporate  Information 
Architecture.  Currently,  the  COBOL  routines  are  l^ing  convened  to  access 
the  ORACLE  relational  database  management  system.  It  is  envisioned  that 
the  port  will  be  tested  and  completed  by  midspring  1992. 
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